Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Waiting forever for OGR lock in GetFeatureInfo #4869
I have an issue with MapServer 6.4 (as shipped by UbuntuGIS in their 6.4.1-3 release).
This works nicely in WMS GetImage mode, draws images like it should.
However, trying to do a GetFeatureImage request leads to the process hanging forever, and not returning a result. Calling mapserv on the command line reveals that the result is indeed written out correctly but afterwards the process never terminates.
I found that the holdup was in msOGRFileClose when it tries to ACQUIRE_OGR_LOCK after calling msConnPoolRelease. I haven't debugged this enough to understand why the lock is not available, however:
I have a hunch that this might be because I am accessing the same SpatiaLite files through each of my TILEINDEX files (pointing to a different layer inside the SpatiaLite file of course).
I should have known this was coming ;)
I tried to build a minimal test case to reproduce the bug. On my Ubuntu 12.04/Mapserver 6.4.1 setup, the following steps are required to reproduce:
Mapserver binary, gdal-bin (for ogrtindex), Spatialite.
Create Spatialite Files
Create two databases, with two layers each, and two points on each layer. Note that for simplicity both layers have an identical signature here, while they had different signatures in my original use case.
Create TILEINDEX files
Note that in this particular case, where layer1 and layer2 share signatures, it would be possible to work with just one TILEINDEX file covering both layers. However in other situations where layers are different, the above is required.
Create a file map.map with this content:
Note this references a non-existing template file which is not relevant to our example.
Test your Setup
Run this command (line split for easier reading):
Now run this command:
This queries for the red dot that is north-east of and closest to the centre of the image. The reply is
and there you should have it - the process does not terminate. Trace the process and you'll find it waiting to acquire a lock.
(SIde note - if you supply x/y coordinates for which no data is found, the program terminates correctly.)
I hope that this might help someone more knowledgeable than myself to isolate the problem. It does seem to be a bit of an esoteric case and therefore not something super-high priority I guess.