[mapserver] Java VM Crashes using the Mapscript API

[Umberto Nicoletti]

For load and stress testing of my web apps (but it can be used for web
services and databases too) I use jmeter

http://jakarta.apache.org/jmeter

It is an excellent tool that will also allow to do distributed testing
as the request can be dispatched to n clients controlled by a single
one. It also has support for cookie-based sessions which is not
available in other products.

Best regards,
Umberto

On 11/18/05, umn-ms at hydrotec.de <umn-ms at hydrotec.de> wrote:
>
> Hallo Umberto
>
> Where to start?
>
> > In my applications I *never* create mapscript objects except for the
>  > main mapObj (I do not add layers, classes or anything else in Java
>  > code). This should explain why I do not see a reason for calling
>  > delete explicitly.
>
> The delete-issue is indeed only necessary if one creates Java-Wrappers
> on sub-objects.
>
> The example in
> http://article.gmane.org/gmane.comp.gis.mapserver.user/11678
> also bases on creating sub-objects.
>
> > I would suggest that this affirmation be checked against code because
>  > I am not sure that the swig glue code will always be safe with regard
>  > to double frees. In general I do not see any possible benefit coming
>  > from this behaviour, but I could be wrong.
>
> On the "double free"-aspect: The delete's code code looks like this:
>
>   public void delete() {
>     if(swigCPtr != 0 && swigCMemOwn) {
>       swigCMemOwn = false;
>       mapscriptJNI.delete_mapObj(swigCPtr);
>     }
>     swigCPtr = 0;
>   }
> So calling "delete" many times is harmless.
>
> > In fact I disagree when you say that this requires 'only small
>  > changes', this is a major effort:
>  > - keep in mind that the core swig code is also used by other languages
>  > and to my knowledge in python there is no need to do garbage
>  > collection yourself, so we should write swig glue code especially for
>  > Java.
>
> I have to confess, that "Swig" is a point I've overseen.
> "only small changes" didn't take the swig-process into account,
> but only the java-code swig creates. (And no doubt a swig-way
> is hardly needed.) Mmmh...
>
> Would be intersting to see how other Java/Swig-Apps manage this.
>
> > - finally there is the enormous problem of global variables in
>  > mapserver sources which make some of it not thread safe.
>
> Using java-"synchronized" frequently is unfortunaltey indispensable
> for now.
>
> > BTW: how do you stress test your application (software, configuration,
> etc)?
>
> We wrote a Java Programm which creates n threads, for simulating n browsers.
>
> Each thread sleeps for 2 or 3 seconds and then issues a http-Request
> to the server to force the server to create a map.
> This is cycled for m-times creating m maps.
>
> The requests vary the map-extends which are produced.
>
> Example: n=4 Browsers; Each making m=5000 requests.
> (runs quite long ...)
>
> I do remember, that some time ago you suggested a special software
> for this task, but we found it easier to write a Java-Programm on our own.
>
> > > - On our testsystem it runs very fine for weeks.
>  ...
> > > - On the customers (production-)machine we still have Tomcat crashes
> about
> ...
>  > ... Java mapscript can be used ... with reasonable stability
> > and performance when only the following components are involved:
>  ...
>  > - raster support (via gdal)
>
> Mmh. Could be, that our customers production-machine uses rasters and
> the testsystem only Shape and Oracle.
> I will have a closer look, wether this makes the difference.
>
> Have a nice weekend
> Benedikt
>
>