[mapguide-internals] Server rendering incomplete tiles - Defect or Feature??

[Traian Stanev]

That's understandable, and I'm not trying to justify the behavior, but I am trying to say that fixing the out-of-memory problem is probably more important to focus on from practical standpoint, unless you say that you see this layer error problem happen a lot in your published maps, for reasons other than out-of-memory. 


Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Monday, May 04, 2009 2:26 PM
To: 'mapguide-internals at lists.osgeo.org'
Subject: Re: [mapguide-internals] Server rendering incomplete tiles - Defect or Feature??

Hey, it's all about me :)

Quite apart from UV's case, I would rather return a big red X or a pink square that I'll hear about right quick and be able to address, than have a developer make an expensive decision based on a wrong map.  Disclaimers only go so far.

If that parameter was available, I'd definitely turn it on for production servers, not just for development.

Jason


----- Original Message -----
From: mapguide-internals-bounces at lists.osgeo.org <mapguide-internals-bounces at lists.osgeo.org>
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Sent: Mon May 04 11:09:40 2009
Subject: RE: [mapguide-internals] Server rendering incomplete tiles - Defect	or	Feature??


Right, and another point we need to think about is that this way of reporting error was never really meant to indicate that the server is running out of memory -- which is the problem UV is trying to solve here. Improving the error reporting, while nice to have, is not really addressing the actual problem, which is that there are memory leaks that need to be fixed, or that UV's test case is running simply way too many simultaneous requests, with each request transiently consuming lots of memory during the rendering.

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Trevor Wekel
Sent: Monday, May 04, 2009 2:04 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Server rendering incomplete tiles - Defect or Feature??

That's partially why I didn't include the parameter.  There is no quick and dirty way to return the error message to the client when it is expecting an image.  It may be possible to use our "non-standard" 559 error code with an additional header for more descriptive text.  That would require some investigation and a bunch of additional work for both the ajax and fusion viewers.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Monday, May 04, 2009 11:56 AM
To: 'mapguide-internals at lists.osgeo.org'
Subject: Re: [mapguide-internals] Server rendering incomplete tiles - Defect or Feature??

That would be a reasonable solution if there are cases where people want images at any cost.

How would you propagate up the exceptions for image requests?  Send up a non-standard http status message, or an additional header?  Could JS intercept and display these?  I can't think of a reliable way to do this without actually embedding a warning in the image.   

Jason


----- Original Message -----
From: mapguide-internals-bounces at lists.osgeo.org <mapguide-internals-bounces at lists.osgeo.org>
To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
Sent: Mon May 04 10:49:19 2009
Subject: RE: [mapguide-internals] Server rendering incomplete tiles - Defect	or	Feature??

I considered this as part of the original enhanced logging RFC but didn't have time to put it in.  We could add a "TreatWarningsAsErrors" parameter to serverconfig.ini.  People developing maps or generating tiles could turn it on to get non-fatal stylization errors (ie. warnings) to propagate up from the rendering stack.

As Traian mentioned, failing to draw all layers when only one layer fails is not a great solution.  Ideally, the warnings should be propagated all the way to the UI so users will know when there is something wrong with a layer.  That would be an interesting, and non-trivial, RFC.

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Monday, May 04, 2009 11:18 AM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Server rendering incomplete tiles - Defect or Feature??


It's classic MapGuide behavior to not take down the whole map because of a single layer -- a single layer that could be having intermittent issues with things like network connectivity to its data source for example. This is because most MapGuide applications have historically been live apps (and not offline tile generators).

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Sunday, May 03, 2009 10:31 PM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] Server rendering incomplete tiles - Defect or Feature??

I studied the Stylize Layer code in MappingUtil.cpp.

The exception handler (line 760-790) at the end of the layer loop is catching exceptions and not doing anything about it (except logging) AFAIK this would explain why the server generates incomplete == wrong tiles without letting us know about it.
If I is misinterpeted the code please tell me why.

WHATS HAPPENING

Currently, mapping errors including the FDO access are replaced with a simple log message and the layer is omitted from the currently rendered tile. This gives all kinds of visual effects on the tile.
On a large map its virtually impossible to identify the wrong tiles. 
Just rerendering might require more than a day.

Currently I believe the server is giving a wrong system response by delivering such a faulty tile without note via the API.
This would be a major defect for this special class of use cases.
Furthermore, the relation between the log message and the offending tile is very difficult to establish.

If somebody thinks this is correct, please let me know why.

POSSIBLE RESOLUTION
Rethrowing the exception will cause the server to return an exception via the HTTP API causing the tile to fail also on the client side.
It will also stall the server eventually, very similar to the current situation in that the workerthread will cease to serve requests.
_______________________________________________
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
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals