[mapserver] Java VM Crashes using the Mapscript API

Benedikt Rothe umn-ms at HYDROTEC.DE
Fri Nov 18 11:06:58 EST 2005


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

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


More information about the mapserver-users mailing list