Java MapScript issues Servlet

Tue Mar 1 09:32:10 EST 2005

Joe,

You do have the option to turn on thread safety, it's just that
nmake.opt is incomplete.  Its authors are not multi-threading users.
Make sure that the USE_THREAD macro is defined when compiling
mapthread.c.  It's as simple as that.

cheers,
Sean

On Feb 28, 2005, at 8:41 PM, Miller Joseph wrote:

> This is a multi-part message in MIME format.
>
> ------_=_NextPart_001_01C51E11.40BE0E8D
> Content-Type: text/plain;
>         charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> To All,
> Umberto and Mario are correct about the problems I've had.  They are =
> definitely related to the lack of thread safety in my mapscript.dll
> that =
> I built using MS Visual C tools.  Can anyone tell me why I don't have =
> the option to turn on thread safety in nmake.opt (unlike in *Nix
> flavors =
> of the build option files)?  Was it an oversight, future feature or =
> excluded because it is included by default whenever mapserver is built
> =
> in Windows and there is no need to turn it off?
> =20
> Thanks,
> Joe Miller
>
> ________________________________
>
> From: UMN MapServer Users List on behalf of Umberto Nicoletti
> Sent: Mon 2/28/2005 10:31 AM
> To: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: Re: [UMN_MAPSERVER-USERS] Java MapScript issues Servlet
>
>
>
> Quoting "Mario H. Basa" <mhbasa at YAHOO.COM>:
>
>> Hi.
>>
>>> From my experience, Java Mapscript still has some
>> problems with threads, and can still easily bring down
>> Tomcat even with the thread compile option is set.
>> Please correct me if I am wrong.
>>
>
> Yes, that is probably correct, although it is not *that easy*. I have =
> also
> stressed mapscript with jmeter and actually not found errors, but I
> did =
> not
> cover querying.
> That is why I voted for improved thread safety when the devs showed =
> their wishlists.
>
>
>> What I did was I synchronized the class that does the
>> map processing, and now my test app can survive
>> benchmarking with JMeter. Here are my results as
>> compared with a simillar PHP CGI program:
>>
>
> This is definitely a correct workaround.
>
>> 4 threads (requests) per second, repeated 25 times
>>
>> PHP Mapscript 1.8 to 1.9 pages per second
>> Java Mapscript 2.3 to 2.5 pages per second
>>
>> I was honestly surprised with the result and it is
>> encouraging me to work with Java Mapscript even in a
>> synchronized mode.
>>
>
> Were you using apache 1.3 or 2.x in the php tests? Apache 1.3 uses a =
> fork based
> model, that while being extremely safe and sound is not as fast as a =
> threaded
> model. Apache 2.x has threads and should be faster.
>
> Regards,
> Umberto
>
>> mario
>> yokohama,japan
>>
>>
>> --- Joseph Miller <miller_joseph at BAH.COM> wrote:
>>
>>> Umberto,
>>>
>>> 1)I don't think I compiled specifically with
>>> multi-threading because it
>>> wasn't an option listed in the nmake.opt for
>>> Microsoft Visual C++  options
>>> file???  The last I heard multithreading was not
>>> even on the horizon for
>>> mapserver and yet I see it in the Unix build options
>>> file?  What do I need
>>> to do this?
>>>
>>> 2)I tried both options you mentioned, I had the
>>> problem when passed the
>>> same mapObj from request to request and stored it in
>>> the session and when I
>>> set it to null after every request and instantiated
>>> it and assigned
>>> attributes based on other variables stored in the
>>> requests and sessions?
>>> I'm assuming the latter is preferred?
>>>
>>> Thanks,
>>> Joe Miller
>>>
>>> On Mon, 28 Feb 2005 09:44:21 +0100, Umberto
>>> Nicoletti
>>> <unicoletti at PROMETEO.IT> wrote:
>>>
>>>> Did you enable threads support?
>>>> Java, and especially servlets, are definitely
>>> highly concurrent
>>>> environment, so you have to enable thread support
>>> when compiling
>>>> mapserver and mapscript. One very problematic spot
>>> with regards to
>>>> threads is in fact the parser of .map files.
>>>>
>>>> Do you attempt to reuse the same mapObj across
>>> multiple requests or just
>>>> create one and dispose as soon as you are done
>>> within a single request?
>>>>
>>>> HTH,
>>>> Umberto
>>>>
>>>>
>>>> On Mon, 2005-02-28 at 00:53 -0500, Miller Joseph
>>> wrote:
>>>>> Hi,
>>>>> I'm having a baffling problem with a nightly
>>> build of Java Mapscript
>>>>> from about a month ago that I am running on
>>> Windows 2000 with Tomcat
>>>>> 5.5.4.
>>>>>
>>>>> The symptom I see is that I can generate the
>>> default image but after the
>>>>> fourth or fifth time that I pass a new envelope
>>> to change the extent of
>>>>> the image I get the following error:
>>>>>
>>>>> The relevant part of the stack trace:
>>>>> java.lang.UnknownError: Failed to draw layer
>>> named 'world'.
>>>>>         at
>>>
>> edu.umn.gis.mapscript.mapscriptJNI.mapObj_draw(Native
>>> Method)
>>>>>         at
>>> edu.umn.gis.mapscript.mapObj.draw(mapObj.java:397)
>>>>>
>>>>> Occasionally I'll get a flex scanner error or
>>> tomcat will crash with an
>>>>> Exception_Access_Violation memmove error similar
>>> to the one referred to
>>>>> here:
>>>>>
>>>
>> =
> http://forum.java.sun.com/thread.jspa?
> forumID=3D52&messageID=3D1124599&th=
> rea
>>>>> dID=3D286832
>>>>>
>>>>> All of this happens whether I instatiate new
>>> instances of the mapObj and
>>>>> set everything to null or if I use the same
>>> mapObj throughout and only
>>>>> after a few passes, suggesting to me that there
>>> is a memory issue
>>>>> somewhere.  I can pass on some specific code, but
>>> all I am really doing
>>>>> is creating new envelopes to store extents and
>>> then assigning them to
>>>>> the mapObj or extracting the corner coordinates
>>> and setting the extent
>>>>> with them.
>>>>>
>>>>> I've been fighting this for a frustrating week
>>> now.  Does anyone have
>>>>> any advice?
>>>>>
>>>>> Thanks,
>>>>> Joe Miller
>>>> --
>>>> Umberto Nicoletti
>>> <Mercury> At that point it
>>> will
>>>> +390415701366   unicoletti at prometeo.it
>>> compile, but segfault, as
>>> it should..
>>>> Prometeo S.R.L. The Software Experience
>>>
>>> Umberto,
>>>
>>> 1)I don't think I compiled specifically with
>>> multi-threading because it
>>> wasn't an option listed in the nmake.opt for
>>> Microsoft Visual C++  options
>>> file???  The last I heard multithreading was not
>>> even on the horizon for
>>> mapserver and yet I see it in the Unix build options
>>> file?  What do I need
>>> to do this?
>>>
>>> 2)I tried both options you mentioned, I had the
>>> problem when passed the
>>> same mapObj from request to request and stored it in
>>> the session and when I
>>> set it to null after every request and instantiated
>>> it and assigned
>>> attributes based on other variables stored in the
>>> requests and sessions?
>>> I'm assuming the latter is preferred?
>>>
>>> Thanks,
>>> Joe Miller
>>>
>>
>>
>>
>>
>> __________________________________
>> Do you Yahoo!?
>> Yahoo! Sports - Sign up for Fantasy Baseball.
>> http://baseball.fantasysports.yahoo.com/
>>
>
--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies