<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7226.0">
<TITLE>Re: [UMN_MAPSERVER-USERS] Java MapScript issues Servlet</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText36470 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Sean,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Thanks for the heads up, usually I remember
to run a make clean for the cgi executable but forget when compiling the
mapscripts, but not this time. I was finally able to get it to work by
compiling using the method you suggested and by using Mario's suggestion to
strategically place "synchronized" statements to lock down resources for
threads. Specifically I locked down the mapObj during map creation and
when running a draw operation and based on what Mario and Umberto said, I locked
down the String variable that was storing the path to my mapfile.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>This last one took me a long time to figure
out and I would like to suggest that the next version of the Swig Mapscript
include a mapObj constructor that takes in a file object (rather than a string
referring to the path) or something like this so that the file itself can be
locked down by the thread while parsing occurs (it looks like parsing occurs
when the mapObj is instantiated and when it draws to an image??). I will
add this to bugzilla.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Thanks again,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>Joe Miller</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> UMN MapServer Users List on behalf of Sean
Gillies<BR><B>Sent:</B> Tue 3/1/2005 12:32 PM<BR><B>To:</B>
MAPSERVER-USERS@LISTS.UMN.EDU<BR><B>Subject:</B> Re: [UMN_MAPSERVER-USERS] Java
MapScript issues Servlet<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Joe,<BR><BR>Make sure to clean up the existing .obj files,
sometimes we all forget<BR>this. If you did, nevermind :)<BR><BR>As soon
as you can start to isolate the problems, enter them into<BR>MapServer's
bugzilla<BR><BR> <A
href="http://mapserver.gis.umn.edu/bugs/enter_bug.cgi">http://mapserver.gis.umn.edu/bugs/enter_bug.cgi</A><BR><BR>under
the Mapscript-SWIG component. That's the best way for us to team<BR>up on
the bugs.<BR><BR>cheers,<BR>Sean<BR><BR>On Mar 1, 2005, at 10:19 AM, Miller
Joseph wrote:<BR><BR>> Thanks Sean. When you say defined I'm assuming
that you mean that a<BR>> variable equal to<BR>><BR>> "-DUSE_THREAD"
should be included as one of the MS_DEFS at the end of<BR>> the nmake.opt
file? I did that and the build seemed to run fine. If<BR>> that
is all I need to do, then I am still having memory problems that<BR>> I will
pass on to Umberto<sigh>.<BR>><BR>> Joe Miller<BR>><BR>> From:
Sean Gillies [<A
href="mailto:sgillies@frii.com">mailto:sgillies@frii.com</A>]<BR>> Sent: Tue
3/1/2005 9:32 AM<BR>> To: Miller Joseph<BR>> Cc:
MAPSERVER-USERS@LISTS.UMN.EDU<BR>> Subject: Re: Java MapScript issues
Servlet<BR>><BR>><BR>> Joe,<BR>><BR>> You do have the option to
turn on thread safety, it's just that <BR>> nmake.opt is
incomplete. Its authors are not multi-threading users. <BR>>
Make sure that the USE_THREAD macro is defined when compiling <BR>>
mapthread.c. It's as simple as that.<BR>><BR>> cheers,<BR>>
Sean<BR>><BR>> On Feb 28, 2005, at 8:41 PM, Miller Joseph
wrote:<BR>><BR>> > This is a multi-part message in MIME format.<BR>>
><BR>> > ------_=_NextPart_001_01C51E11.40BE0E8D<BR>> >
Content-Type: text/plain;<BR>>
>
charset="iso-8859-1"<BR>> > Content-Transfer-Encoding:
quoted-printable<BR>> ><BR>> > To All,<BR>> > Umberto and
Mario are correct about the problems I've had. They are<BR>> =<BR>>
> definitely related to the lack of thread safety in my
mapscript.dll <BR>> > that =<BR>> > I built using MS Visual C
tools. Can anyone tell me why I don't<BR>> have =<BR>> > the
option to turn on thread safety in nmake.opt (unlike in *Nix <BR>> >
flavors =<BR>> > of the build option files)? Was it an oversight,
future feature or =<BR>> > excluded because it is included by default
whenever mapserver is<BR>> built <BR>> > =<BR>> > in Windows
and there is no need to turn it off?<BR>> > =20<BR>> >
Thanks,<BR>> > Joe Miller<BR>> ><BR>> >
________________________________<BR>> ><BR>> > From: UMN MapServer
Users List on behalf of Umberto Nicoletti<BR>> > Sent: Mon 2/28/2005 10:31
AM<BR>> > To: MAPSERVER-USERS@LISTS.UMN.EDU<BR>> > Subject: Re:
[UMN_MAPSERVER-USERS] Java MapScript issues Servlet<BR>> ><BR>>
><BR>> ><BR>> > Quoting "Mario H. Basa"
<mhbasa@YAHOO.COM>:<BR>> ><BR>> >> Hi.<BR>>
>><BR>> >>> From my experience, Java Mapscript still has
some<BR>> >> problems with threads, and can still easily bring
down<BR>> >> Tomcat even with the thread compile option is set.<BR>>
>> Please correct me if I am wrong.<BR>> >><BR>> ><BR>>
> Yes, that is probably correct, although it is not *that easy*. I<BR>>
have =<BR>> > also<BR>> > stressed mapscript with jmeter and
actually not found errors, but I <BR>> > did =<BR>> >
not<BR>> > cover querying.<BR>> > That is why I voted for improved
thread safety when the devs showed =<BR>> > their wishlists.<BR>>
><BR>> ><BR>> >> What I did was I synchronized the class that
does the<BR>> >> map processing, and now my test app can
survive<BR>> >> benchmarking with JMeter. Here are my results
as<BR>> >> compared with a simillar PHP CGI program:<BR>>
>><BR>> ><BR>> > This is definitely a correct
workaround.<BR>> ><BR>> >> 4 threads (requests) per second,
repeated 25 times<BR>> >><BR>> >> PHP Mapscript 1.8 to 1.9
pages per second<BR>> >> Java Mapscript 2.3 to 2.5 pages per
second<BR>> >><BR>> >> I was honestly surprised with the
result and it is<BR>> >> encouraging me to work with Java Mapscript
even in a<BR>> >> synchronized mode.<BR>> >><BR>>
><BR>> > Were you using apache 1.3 or 2.x in the php tests? Apache 1.3
uses a<BR>> =<BR>> > fork based<BR>> > model, that while being
extremely safe and sound is not as fast as a<BR>> =<BR>> >
threaded<BR>> > model. Apache 2.x has threads and should be
faster.<BR>> ><BR>> > Regards,<BR>> > Umberto<BR>>
><BR>> >> mario<BR>> >> yokohama,japan<BR>>
>><BR>> >><BR>> >> --- Joseph Miller
<miller_joseph@BAH.COM> wrote:<BR>> >><BR>> >>>
Umberto,<BR>> >>><BR>> >>> 1)I don't think I compiled
specifically with<BR>> >>> multi-threading because it<BR>>
>>> wasn't an option listed in the nmake.opt for<BR>> >>>
Microsoft Visual C++ options<BR>> >>> file??? The last I
heard multithreading was not<BR>> >>> even on the horizon
for<BR>> >>> mapserver and yet I see it in the Unix build
options<BR>> >>> file? What do I need<BR>> >>> to
do this?<BR>> >>><BR>> >>> 2)I tried both options you
mentioned, I had the<BR>> >>> problem when passed the<BR>>
>>> same mapObj from request to request and stored it in<BR>>
>>> the session and when I<BR>> >>> set it to null after
every request and instantiated<BR>> >>> it and assigned<BR>>
>>> attributes based on other variables stored in the<BR>>
>>> requests and sessions?<BR>> >>> I'm assuming the latter
is preferred?<BR>> >>><BR>> >>> Thanks,<BR>>
>>> Joe Miller<BR>> >>><BR>> >>> On Mon, 28 Feb
2005 09:44:21 +0100, Umberto<BR>> >>> Nicoletti<BR>> >>>
<unicoletti@PROMETEO.IT> wrote:<BR>> >>><BR>>
>>>> Did you enable threads support?<BR>> >>>> Java,
and especially servlets, are definitely<BR>> >>> highly
concurrent<BR>> >>>> environment, so you have to enable thread
support<BR>> >>> when compiling<BR>> >>>> mapserver
and mapscript. One very problematic spot<BR>> >>> with regards
to<BR>> >>>> threads is in fact the parser of .map files.<BR>>
>>>><BR>> >>>> Do you attempt to reuse the same
mapObj across<BR>> >>> multiple requests or just<BR>>
>>>> create one and dispose as soon as you are done<BR>>
>>> within a single request?<BR>> >>>><BR>>
>>>> HTH,<BR>> >>>> Umberto<BR>>
>>>><BR>> >>>><BR>> >>>> On Mon,
2005-02-28 at 00:53 -0500, Miller Joseph<BR>> >>> wrote:<BR>>
>>>>> Hi,<BR>> >>>>> I'm having a baffling
problem with a nightly<BR>> >>> build of Java Mapscript<BR>>
>>>>> from about a month ago that I am running on<BR>>
>>> Windows 2000 with Tomcat<BR>> >>>>>
5.5.4.<BR>> >>>>><BR>> >>>>> The symptom I
see is that I can generate the<BR>> >>> default image but after
the<BR>> >>>>> fourth or fifth time that I pass a new
envelope<BR>> >>> to change the extent of<BR>>
>>>>> the image I get the following error:<BR>>
>>>>><BR>> >>>>> The relevant part of the stack
trace:<BR>> >>>>> java.lang.UnknownError: Failed to draw
layer<BR>> >>> named 'world'.<BR>>
>>>>> at<BR>>
>>><BR>> >>
edu.umn.gis.mapscript.mapscriptJNI.mapObj_draw(Native<BR>> >>>
Method)<BR>>
>>>>> at<BR>>
>>> edu.umn.gis.mapscript.mapObj.draw(mapObj.java:397)<BR>>
>>>>><BR>> >>>>> Occasionally I'll get a flex
scanner error or<BR>> >>> tomcat will crash with an<BR>>
>>>>> Exception_Access_Violation memmove error similar<BR>>
>>> to the one referred to<BR>> >>>>> here:<BR>>
>>>>><BR>> >>><BR>> >> =<BR>> > <A
href="http://forum.java.sun.com/thread.jspa">http://forum.java.sun.com/thread.jspa</A>?<BR>>
> forumID=3D52&messageID=3D1124599&th=<BR>> > rea<BR>>
>>>>> dID=3D286832<BR>> >>>>><BR>>
>>>>> All of this happens whether I instatiate new<BR>>
>>> instances of the mapObj and<BR>> >>>>> set
everything to null or if I use the same<BR>> >>> mapObj throughout
and only<BR>> >>>>> after a few passes, suggesting to me that
there<BR>> >>> is a memory issue<BR>> >>>>>
somewhere. I can pass on some specific code, but<BR>> >>> all
I am really doing<BR>> >>>>> is creating new envelopes to
store extents and<BR>> >>> then assigning them to<BR>>
>>>>> the mapObj or extracting the corner coordinates<BR>>
>>> and setting the extent<BR>> >>>>> with
them.<BR>> >>>>><BR>> >>>>> I've been
fighting this for a frustrating week<BR>> >>> now. Does anyone
have<BR>> >>>>> any advice?<BR>>
>>>>><BR>> >>>>> Thanks,<BR>>
>>>>> Joe Miller<BR>> >>>> --<BR>>
>>>> Umberto Nicoletti<BR>> >>> <Mercury> At that
point it<BR>> >>> will<BR>> >>>>
+390415701366 unicoletti@prometeo.it<BR>> >>> compile,
but segfault, as<BR>> >>> it should..<BR>> >>>>
Prometeo S.R.L. The Software Experience<BR>> >>><BR>>
>>> Umberto,<BR>> >>><BR>> >>> 1)I don't think
I compiled specifically with<BR>> >>> multi-threading because
it<BR>> >>> wasn't an option listed in the nmake.opt for<BR>>
>>> Microsoft Visual C++ options<BR>> >>>
file??? The last I heard multithreading was not<BR>> >>> even
on the horizon for<BR>> >>> mapserver and yet I see it in the Unix
build options<BR>> >>> file? What do I need<BR>>
>>> to do this?<BR>> >>><BR>> >>> 2)I tried
both options you mentioned, I had the<BR>> >>> problem when passed
the<BR>> >>> same mapObj from request to request and stored it
in<BR>> >>> the session and when I<BR>> >>> set it to
null after every request and instantiated<BR>> >>> it and
assigned<BR>> >>> attributes based on other variables stored in
the<BR>> >>> requests and sessions?<BR>> >>> I'm
assuming the latter is preferred?<BR>> >>><BR>> >>>
Thanks,<BR>> >>> Joe Miller<BR>> >>><BR>>
>><BR>> >><BR>> >><BR>> >><BR>> >>
__________________________________<BR>> >> Do you Yahoo!?<BR>>
>> Yahoo! Sports - Sign up for Fantasy Baseball.<BR>> >> <A
href="http://baseball.fantasysports.yahoo.com/">http://baseball.fantasysports.yahoo.com/</A><BR>>
>><BR>> ><BR>> --<BR>> Sean Gillies<BR>> sgillies at frii
dot com<BR>> <A
href="http://users.frii.com/sgillies">http://users.frii.com/sgillies</A><BR>><BR></FONT></P></DIV>
</BODY>
</HTML>