[Mapserver-users] WMS server - client communication error

[Sean Gillies]

On 07/mag/04, at 10:40, Howard Butler wrote:

> At 11:08 AM 5/7/2004, Sean Gillies wrote:
>
>> On 07/mag/04, at 08:47, Daniel Morissette wrote:
>>
>>> Alexandros Chimarios wrote:
>>>> Traceback (most recent call last):
>>>>   File "./src/test.py", line 131, in ?
>>>>     image = mo.draw();
>>>>   File "/usr/lib/python2.2/site-packages/mapscript.py", line 1783,  
>>>> in draw
>>>>     def draw(*args): return apply(_mapscript.mapObj_draw,args)
>>>> _mapscript.MapServerError: msLookupHashTable: Hash table error.  
>>>> Invalid hash table or key
>>>
>>> A similar problem was reported a few weeks ago:
>>>
>>> http://lists.gis.umn.edu/pipermail/mapserver-dev/2004-April/ 
>>> 000955.html
>>>
>>> In this case it was with python as well, and it was not possible to  
>>> reproduce with the regular CGI. Perhaps there is something specific  
>>> to that flavour of MapScript?  I would suggest that you file a bug  
>>> about this.
>>>
>>> Daniel
>>
>> Alexandros,
>>
>> The Python mapscript module is set up so that the MapServer error  
>> stack is
>> checked after method calls (such as mapObj.draw), MapServer errors are
>> converted to Python exceptions and are raised.
>>
>> Somewhere in msDrawMap, maybe in the WMS HTTP request code,  
>> msLookupHashTable
>> is being used to access layer or map metadata and is not finding  
>> something
>> it expects.  Maybe your mapfile lacks a WMS metadata parameter?
>> In the CGI MapServer, such an error will be reported but will
>> not necessarily stop execution of the program.  With the Python  
>> MapScript,
>> unhandled exceptions will stop execution.
>>
>> I suggest that you try some code like this for now:
>>
>>     image = mo.prepareImage() # so that it is defined outside the  
>> try/except
>>     try:
>>         image = mo.draw()
>>     except MapServerError:
>>         pass
>>
>> Let me know how it goes and together we can work towards a better
>> solution.
>>
>> cheers,
>> Sean
>>
>
> Sean,
>
> prepareImage doesn't cure it.  For me, it was only happening on WMS  
> images that needed to be projected using GDAL.  I have an Albers map  
> that I am pulling in a UTM 15 image where it is causing a problem for  
> me.
>
> I suspect an error is being put on the stack that is silenced by the  
> WMS code.  Most things don't pick up on it, but Python is very  
> sensitive to not silencing exceptions ;)
>
> I also know that a WMS parameter is not missing because the image is  
> successfully download (I can send debug info along if requested).
>
> Howard
>
>

Howard, it isn't that prepareImage cures anything, I'm just using it so  
that
image is defined outside the try/except blocks and can be used after  
we've
dodged the hash lookup error.

I looked into msDrawWMSLayerLow(), which is called in your case and  
Alexandros'.
A few lines in, we try to look up "wms_sld_body" and "wms_sld_url" in  
the
layer metadata ... if you don't have these defined in your layer,
msLookupHashTable() is going to throw an error that stops the Python  
interpreter.
I wouldn't be surprised if there are more such cases, and as the number  
of
WMS features grow, there will be ever more.

IMO, msLookupHashTable() should throw errors like this so that, in  
Python,
layer.getMetaData("foo") raises an exception just like adict["foo"]  
raises
a KeyError if "foo" is not present in the dictionary.  Looks like we  
have to add
some code to msDrawWMSLayerLow to delete these particular errors before  
they
can hit the Python interpreter.

Sean


--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies