[MS4W-Users] php-cgi crash with PostGIS

[Jeff McKenna]

Johan Forsman wrote:
> Hi Jeff, please see bottom for my reply.
> 
>> -----Original Message-----
>> From: ms4w-users-bounces at lists.maptools.org [mailto:ms4w-users-
>> bounces at lists.maptools.org] On Behalf Of Jeff McKenna
>> Sent: Thursday, December 03, 2009 11:30 AM
>> To: ms4w-users at lists.maptools.org
>> Subject: Re: [MS4W-Users] php-cgi crash with PostGIS
>>
>> Johan Forsman wrote:
>>> Hello All:
>>>
>>> I do not know what the proper place to report this issue may be, but I
>> thought I would start here hoping you can steer me in the right direction.
>>> We have a small, internal to my organization, mapserver on WinXP,
>> currently using MS4W 3.0 beta 6, with GeoMoose 2.0.1, primarily with
>> shapefiles. The query function in GeoMoose is too slow for practical use
>> for a particular point-data set and it was suggested by the developers to
>> try the PostGIS system instead to speed up response time of the query.
>>> I installed and configured PostgreSQL 8.4.0 and PostGIS 1.4 without
>> issues, and I am using pgAdmin to help me along with configuration. I
>> created a new database "sdwp" instead of using the default "postgres"
>> database
>>> I ingested the shapefile into PostGIS without issues and built an index
>> on the field of interest to the query, then changed the mapfile to point
>> to PostGIS instead of the shapefile.
>>> Display of data from PostGIS works fine, but every time I execute the
>> query there is a crash of php-cgi.exe on the server. The message on the
>> server is the generic crash message from WinXP: CGI/FastCGI has
>> encountered a problem and needs to close.
>>> One strange thing is that the crash occurs in two separate modules
>> depending on which dataset I query against.
>>> Dataset A: Full dataset of ~180000 water wells.
>>> Dataset B: Subset of dataset A, ~20000 water wells.
>>>
>>> Both are point data, and were ingested from individual shapefiles, and
>> are currently stored as separate tables in the same PostGIS database, with
>> separate indexes.
>>> For dataset A the crash first occurs in gdal17dev.dll, then repeatedly
>> in ntdll.dll shortly after clicking the "Don't Send" button (Remote
>> Desktop control). I click the Don't Send button several times to dismiss
>> the crash dialogs that pop up.
>>> For dataset B the crash occurs only in ntdll.dll, and only once per
>> query attempt.
>>> Once the crash has occurred I click the Don't Send button in the crash
>> dialog on the server and one of two things will happen depending on the
>> active dataset.
>>> Dataset A: 1) if there ARE NO matches for the query parameter GeoMoose
>> immediately returns a message to that effect; 2) if there ARE matches to
>> the query parameter GeoMoose returns the correct number of records.
>>> Dataset B: 1) if there ARE NO matches for the query parameter GeoMoose
>> immediately returns a message to that effect; 2) if there ARE  matches to
>> the query parameter the server returns an Unhandled Request return,
>> Internal Server Error message after a several-second delay.
>>> There are more permutations than the above if I change the "turn
>> highlight layer on" and/or "zoom to first hit" properties inside of the
>> GeoMoose mapbook.
>>> I don't even know where to start collecting evidence. Red herrings
>> everywhere I suspect. This problem does not appear if I use shapefiles,
>> but the query takes too long for practical use. PHP issue? GeoMoose issue?
>> Mapserver issue? Windows issue? PostGIS issue? Yes to all or some of that?
>>> There is an error shown in the PostGIS log, but I do not know if it is
>> relevant (symptom or disease):
>>> 2009-12-03 09:23:24 CSTLOG:  could not receive data from client: No
>> connection could be made because the target machine actively refused it.
>>
>>> 2009-12-03 09:23:24 CSTLOG:  unexpected EOF on client connection
>>>
>>> What information do I need to collect, how do I collect it, and where
>> should I send it to help with resolving this?
>>> Thank you for your consideration.
>>>
>> Johan,
>>
>> Yes that does sound tricky.
>>
>> I think you should try to take as many factors out of the equation as
>> you can and still generate the error:
>>
>> - remove GeoMoose, use a simple MapServer CGI viewer to execute query
>> - remove MS4W, try your tests with another Windows package like FWTools
>> - narrow the data down to the smallest subset that will still throw the
>> error (one table with one record and one column, if possible)
>>
>> One you've done some of those you could possibly package a test package
>> (mapfile with one layer, shapefile that has only a few records and only
>> the fields that you need for display, commands to import into postgis)
>> and post here or to the other lists that you are trying.  If you're
>> lucky someone will take time out of this/her day to run your test
>> package (and your chances for this to occur greatly increase by how much
>> time your spend beforehand in making the package the smallest you can).
>>
> 
> Ok, after some wrangling (correct syntax was difficult to determine) figuring out how to issue a CGI query straight in the address bar of my browser I have a partial report. Issuing the string
> 
> http://geoview/cgi-bin/mapserv.exe?map=/ms4w/apps/geomoose2/maps/sdwp/wells/wells.map&layers=ldotd_all&mode=itemnquery&qlayer=ldotd_all&qitem=regowner&qstring=(regowner='RED OAK DEVELOP')
> 
> returns twelve results in 7 seconds. Using the same search term with the GeoMoose search tool returns the same 12 results, but it takes a total of 70 seconds, with the php-cgi.exe crash in gdal17dev.dll at 65 seconds. That is the crash dialog on the server appears at 65 seconds, it may be occurring slightly before that due to the DrWatson delay to construct the dialog. Is there a 60 second magic threshold somewhere?
> 
> Based on the data above I may be inclined to suggest the issue is neither with PHP, CGI, nor Mapserver.
> 

Hmm, interesting.  Good work piecing the CGI request together.  Now I 
guess your next step is to find out the exact MapServer CGI request that 
GeoMoose is making through the 'GeoMoose search tool', and try that in a 
browser (but then you're into GeoMoose-land and this issue should be 
discussed on the GeoMoose lists).

-jeff



-- 
Jeff McKenna
FOSS4G Consulting and Training Services
http://www.gatewaygeomatics.com/