Java MapScript issues Servlet

Miller Joseph miller_joseph at BAH.COM
Wed Mar 2 09:41:40 EST 2005 

Sean,
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.
 
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.
 
Thanks again,
Joe Miller

________________________________

From: UMN MapServer Users List on behalf of Sean Gillies
Sent: Tue 3/1/2005 12:32 PM
To: MAPSERVER-USERS at LISTS.UMN.EDU
Subject: Re: [UMN_MAPSERVER-USERS] Java MapScript issues Servlet



Joe,

Make sure to clean up the existing .obj files, sometimes we all forget
this.  If you did, nevermind :)

As soon as you can start to isolate the problems, enter them into
MapServer's bugzilla

     http://mapserver.gis.umn.edu/bugs/enter_bug.cgi

under the Mapscript-SWIG component.  That's the best way for us to team
up on the bugs.

cheers,
Sean

On Mar 1, 2005, at 10:19 AM, Miller Joseph wrote:

> Thanks Sean.  When you say defined I'm assuming that you mean that a
> variable equal to
>
> "-DUSE_THREAD" should be included as one of the MS_DEFS at the end of
> the nmake.opt file?  I did that and the build seemed to run fine.  If
> that is all I need to do, then I am still having memory problems that
> I will pass on to Umberto<sigh>.
>
> Joe Miller
>
> From: Sean Gillies [mailto:sgillies at frii.com]
> Sent: Tue 3/1/2005 9:32 AM
> To: Miller Joseph
> Cc: MAPSERVER-USERS at LISTS.UMN.EDU
> Subject: Re: Java MapScript issues Servlet
>
>
> 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
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-users/attachments/20050302/ea395e97/attachment.html

More information about the mapserver-users mailing list