[mapguide-internals] Exception Handling for Memory limitations + Patch for #480 & #520

[UV]

exactly thats why my patch only deletes empty files in my ignorance of 
the possible use cases...
however with the retry on the malloc i never could reproduce this 
exception anymore.....
it just gets slower... and slower....

Walt Welton-Lair wrote:
> Note that ByteSink::ToFile is a general purpose method, and so we can't code tile-cache specific behavior in there.  Any tile-specific behavior needs to go into the tile service.  For example, MgServerTileService::SetTile (which writes the image stream to the tile cache) can verify the file was written, and if not do something special.
>
> ________________________________________
> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Zac Spitzer [zac.spitzer at gmail.com]
> Sent: Friday, April 03, 2009 1:26 AM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] Exception Handling for Memory limitations +   Patch for #480 & #520
>
> I tend to agree with jason's point... however, from a performance
> perspective, it means we keep
> hitting the error and throwing an exception. where as a empty file
> avoid's that issue.. what to do?
>
> writing a blank file with an additional file which can be searched
> for, ie 6_6.png.error?
>
> z
>
>
> On Fri, Apr 3, 2009 at 4:16 PM, Jason Birch <Jason.Birch at nanaimo.ca> wrote:
>   
>> This is from a non-technical perspective, but I would _much_ rather have a missing tile than a corrupt tile.  IMO, if an exception is thrown and it's not possible to determine that the file was written without errors, delete it.  I haven't tried this with a recent release, but I think that earlier versions were writing white tiles when exceptions were encountered. Differentiating between these failed tiles and tiles were not corrupt but had minimal information on them was difficult.
>>
>> It would be useful if the logged error included information on which file was being written as well as the reason for the exception.  I've run into a few cases where bad geometry causes rendering exceptions, and tracking these down can be a royal pain.
>>
>> Jason
>>
>> ________________________________________
>> From: Walt Welton-Lair [walt.welton-lair at autodesk.com]
>> Sent: Thursday, April 02, 2009 8:40 PM
>> To: MapGuide Internals Mail List
>> Subject: RE: [mapguide-internals] Exception Handling for Memory limitations     +       Patch for #480 & #520
>>
>> Also, in my change I delete the file if any exception is encountered - in your case you delete it only if it's empty.  Both seem like reasonable choices.  When an exception occurs it's possible the file got written out completely and is valid, but it's also possible it was only partially written and therefore not valid.  Any more thoughts on that?_______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>     
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com
> +61 405 847 168
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>