Waiting forever for OGR lock in GetFeatureInfo

[woodpeck]

I have an issue with MapServer 6.4 (as shipped by UbuntuGIS in their 6.4.1-3 release).

My setup:

• One SpatiaLite file for each continent (europe.sqlite, asia.sqlite etc.). Each has 5 different tables (layer1, layer2, etc.), and the tables are spatially indexed.
• Five TILEINDEX shape files, generated with ogrtindex, each containing one box for each of the continents - tileindex_layer1.shp, tileindex_layer2.shp etc. (It was not possible to work with one TILEINDEX since the tables have different layouts.)
• One Map File with five layers, each layer pointing to a TILEINDEX shape, and rendering the data from that layer.

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:

• replacing RELEASE_OGR_LOCK and ACQUIRE_OGR_LOCK with null operations seems to resolve the problem with no ill effects to my (apache mpm_prefork based) setup.
• accessing a SpatiaLite file directly, instead of through the TILEINDEX method, also works normally.

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).

[tbonfort]

unless you can debug this further, it would help a lot if you could provide us with a testcase that reproduces this (mapfile + data + failing request url)

[woodpeck]

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:

Prerequisites

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.

spatialite db1.sqlite <<EOF
create table layer1(id integer);
select AddGeometryColumn('layer1', 'geom', 4326, 'POINT', 'XY');
insert into layer1 values(1, geomfromtext("POINT(1 1)", 4326));
insert into layer1 values(2, geomfromtext("POINT(2 2)", 4326));
create table layer2(id integer);
select AddGeometryColumn('layer2', 'geom', 4326, 'POINT', 'XY');
insert into layer2 values(1, geomfromtext("POINT(1.5 1.5)", 4326));
insert into layer2 values(2, geomfromtext("POINT(2.5 2.5)", 4326));
EOF

spatialite db2.sqlite <<EOF
create table layer1(id integer);
select AddGeometryColumn('layer1', 'geom', 4326, 'POINT', 'XY');
insert into layer1 values(1, geomfromtext("POINT(-1 -1)", 4326));
insert into layer1 values(2, geomfromtext("POINT(-2 -2)", 4326));
create table layer2(id integer);
select AddGeometryColumn('layer2', 'geom', 4326, 'POINT', 'XY');
insert into layer2 values(1, geomfromtext("POINT(-1.5 -1.5)", 4326));
insert into layer2 values(2, geomfromtext("POINT(-2.5 -2.5)", 4326));
EOF

Create TILEINDEX files

ogrtindex -lname layer1 tileindex_layer1.shp *sqlite
ogrtindex -lname layer2 tileindex_layer2.shp *sqlite

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.

Map File

Create a file map.map with this content:

MAP
    CONFIG MS_ERRORFILE "log.log"
    DEBUG 3

    NAME test
    EXTENT -2 -2 2 2
    PROJECTION
        "init=epsg:4326"
    END

    Symbol
    Name 'circle'
    Type ELLIPSE
    Filled TRUE
    Points
    1 1
    END
    END 

    WEB
        METADATA
            OWS_SERVER_VERSION "1.1.1"
            OWS_SRS "EPSG:4326 EPSG:900913"
            OWS_ENABLE_REQUEST "*"
        END
    END

    LAYER
        NAME layer1
        TYPE POINT
        STATUS ON
        CONNECTIONTYPE OGR
        TILEINDEX "tileindex_layer1.shp"
        TEMPLATE "foo"
        DUMP true
        CLASS
            STYLE
                SYMBOL "circle"
                SIZE 10
                COLOR 255 0 0 
            END
        END
    END

    LAYER
        NAME layer2
        TYPE POINT
        STATUS ON
        CONNECTIONTYPE OGR
        TILEINDEX "tileindex_layer2.shp"
        TEMPLATE "foo"
        DUMP true
        CLASS
            STYLE
                SYMBOL "circle"
                SIZE 10
                COLOR 0 255 0 
            END
        END
    END
END

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):

mapserv -nv QUERY_STRING="map=./map.map&LAYERS=layer1,layer2\
&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap\
&STYLES=&SRS=EPSG%3A4326&BBOX=-4%2C-4%2C4%2C4\
&WIDTH=200&HEIGHT=200" |sed -e "1,2d" > foo.png

View the resulting image; you should see something like this (shadow added here for easier reading):

Reproduce Bug

Now run this command:

mapserv -nv QUERY_STRING="map=./map.map&LAYERS=layer1,layer2\
&FORMAT=image%2Fpng&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetFeatureInfo\
&STYLES=&QUERY_LAYERS=layer1,layer2&INFO_FORMAT=text%2Fplain&x=125&\
y=75&SRS=EPSG%3A4326&BBOX=-4%2C-4%2C4%2C4&WIDTH=200&HEIGHT=200"

This queries for the red dot that is north-east of and closest to the centre of the image. The reply is

Content-Type: text/plain

GetFeatureInfo results:

Layer 'layer1'
  Feature 1: 

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.