WMS Raster Layers should not use CLOSE_CONNECTION=DEFER

[aboudreault]

By default, the gdal dataset connections are opened in DEFER mode excepted for tileindex. This is perfect for single data files but it can a problem for WMS layers. The image of a wms request is saved in a memory buffer and it cannot really have a "shared connection" because we always have to recall the wms request. Although that people doesn't notice that because most just call a small php/python script or use the CGI directly, we can see the problem when we use a bigger script that draw the map multiple times (like precache3.php). The bug can be easily reproduced by loading a map that contains a WMS layer and drawing the map multiple times (without reloading the map).

we should modify the code to close the gdal dataset connection by default for WMS layers.

[sdlime]

Updating component... Steve

[aboudreault]

In fact, the problem is that the memory usage never stop to grow until the script ends.

[dmorissette]

It would be ideal to handle this in msDrawRasterLayerLow() together with a simple if (lp->connectiontype==MS_WMS) in the code that handles the connection_close=defer defaults, but unfortunately the code was modified in ticket #541 to recursively call msDrawLayer() from inside msDrawWMSLayerLow() so that opacity works... and to prevent infinite recursion, msDrawWMSLayerLow() overrides the connectiontype to temporarily set it to MS_SHAPEFILE before calling msDrawLayer()... as a result the function finishes the rendering as if the layer was a regular raster layer.

Here are two options I can think of:

1- Force PROCESSING CLOSE_CONNECTION=NORMAL inside msDrawWMSLayerLow() and reset the value at the end of the function... the simplest, but not the cleanest.

2- Go through a complete cleanup of the handling of WMS layers in the msDrawMap() and msDrawLayer() functions to avoid this recursion problem with WMS layers and allow us to leave the connectiontype untouched... then we could just use a if (lp->connectiontype==MS_WMS) in msDrawRasterLayerLow()... much more work but would leave us with much cleaner code in the end. I've got some ideas on the way we could reorganize things but would need to spend more time in the code to confirm that can work.

[warmerdam]

Daniel,

Do you still plan to address this rework? If not, I could do the simple solution and test it. I'd like this fixed before 6.0, and I feel responsible since it was my change for DEFER stuff that lead to it.