<br><font size=2 face="sans-serif">Hallo Umberto, Fernando, Donovan and
...</font>
<br>
<br><font size=2 face="sans-serif">Thanks for coming back to this point.
This area is also still a big</font>
<br><font size=2 face="sans-serif">problem to me. (Especially I'm happy
about the Java/Oracle-guru-combination </font>
<br><font size=2 face="sans-serif">Fernando/Umberto.)</font>
<br>
<br><font size=2 face="sans-serif">It's maybe usefull to figure out where
we agree and where we disagree:</font>
<br>
<br><font size=2 face="sans-serif">- I disagree to Umberto with the use
of the Java-gc in Mapserver 4.6. I state:</font>
<br><font size=2 face="sans-serif"> As long as Java/Mapserver is
at is is now (Version 4.6.1)</font>
<br><font size=2 face="sans-serif"> one must not rely on gc only.
One has to call delete. </font>
<br><font size=2 face="sans-serif"> To the question of Fernando:
"</font><font size=2><tt>So the question is, where I can call delete?
</tt></font><font size=2 face="sans-serif">"</font>
<br><font size=2 face="sans-serif"> is my rule of thumb: </font>
<br><font size=2 face="sans-serif"> "Call delete on Mapserver-Objects
as soon as you can whenever a delete exists."</font>
<br>
<br><font size=2 face="sans-serif"> As a matter of fact: By doing
so, delete is called more often then necessary, because</font>
<br><font size=2 face="sans-serif"> in many cases the finaliser would
do a good job. But this doesn't matter.</font>
<br>
<br><font size=2 face="sans-serif">- I agree to Umberto that there
is a bug in Java/Mapserver behaviour.</font>
<br><font size=2 face="sans-serif"> My suggestion is obvioulsy not
a solution but a way to live with</font>
<br><font size=2 face="sans-serif"> the software as it is.</font>
<br>
<br><font size=2 face="sans-serif">If we would come to the question "How
<i>should</i> Java/Mapserver behave" </font>
<br><font size=2 face="sans-serif">my <i>personal </i>opinion is to look
at the way the Eclipse-People made SWT.</font>
<br><font size=2 face="sans-serif">They also had the problem, that Java-Objects
enclose ressources which are</font>
<br><font size=2 face="sans-serif">not managed by the Java-VM: http://www.eclipse.org/articles/swt-design-2/swt-design-2.html</font>
<br><font size=2 face="sans-serif">(Rule 1: If you created it, you dispose
it. )</font>
<br><font size=2 face="sans-serif">Following this approache would leave
to only small changes in Java/Mapserver-Code</font>
<br><font size=2 face="sans-serif">but to a different documentation of
the Java/Mapscript-API and it should be clearer</font>
<br><font size=2 face="sans-serif">when a objected has to be delete by
the way an object is created.</font>
<br><font size=2 face="sans-serif">(Actually I suppose, that Umberto will
disagree in this point ... :-) )</font>
<br>
<br><font size=2 face="sans-serif">At last it's maybe usefull to share
experiences in stability:</font>
<br><font size=2 face="sans-serif">We wrote an Oracle-Spatial/Tomcat/Mapserver-Application
(Linux-Suse 9.3)</font>
<br><font size=2 face="sans-serif">- On our testsystem it runs very fine
for weeks.</font>
<br><font size=2 face="sans-serif"> The testsystem even survives
stress-tests, where we simulate some browsers making</font>
<br><font size=2 face="sans-serif"> many requests.</font>
<br><font size=2 face="sans-serif">- On the customers (production-)machine
we still have Tomcat crashes about one or</font>
<br><font size=2 face="sans-serif"> two times the day. We didn't
find a solution (except a watchdog-software which restarts tomcat in </font>
<br><font size=2 face="sans-serif"> the crash-case :-( )</font>
<br><font size=2 face="sans-serif"> This machine also survives
the one- or two-hour stress-tests!</font>
<br><font size=2 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">This happens although I'm quite shure,
that we followed the "delete as soon as possible"-rule.</font>
<br><font size=2 face="sans-serif">Crashes occure often somewhere in the
OCI. </font>
<br><font size=2 face="sans-serif">But I'm not able to be more precise
for the moment, because I have very restricted access to </font>
<br><font size=2 face="sans-serif">the production-machine and crashes which
occure only one or two times a day </font>
<br><font size=2 face="sans-serif">are obviously difficult to analyse.</font>
<br><font size=2 face="sans-serif">(Fernando: That does not necessarily
mean, that the Mapserver-Oracle-Code is buggy. This </font>
<br><font size=2 face="sans-serif">could be a consecutive fault from some
other memory-management-error ...)</font>
<br>
<br><font size=2 face="sans-serif">Benedikt </font>
<br>
<br><font size=2><tt>Umberto Nicoletti <umberto.nicoletti@gmail.com>
schrieb am 18.11.2005 13:09:38:<br>
<br>
> On 11/18/05, Fernando Simon <fsimon@univali.br> wrote:<br>
> > Hi Benedikt and Umberto,<br>
> > Here I'm working with a project that uses JavaMapscript
and I'm with<br>
> > some stability problems. For the project I use Mapserver (I compiled<br>
> > myself, with multi thread support) with just these supports:<br>
> > JavaMapscript, Oracle Spatial (I develop the maporaclespatial.c),
Raster.<br>
> > Sometimes the server (TomCat) crashes in randomly
parts of the code,<br>
> > I suspect that the issue is with Java garbage collector and the
delete<br>
> > function. In the code I did as Benedict suggested, if I create
an object<br>
> > (like layer, class, style....), after I finished all the operations
with<br>
> > this object I delete it (using delete).<br>
> > But Umberto, wrote, correct me if I'm wrong, that
he don't use the<br>
> > delete function. So the question is, where I can call delete?
For what<br>
> > objects can I use delete?<br>
> <br>
> To be exact I wrote:<br>
> <br>
> /quote<br>
> <br>
> [...] this is why I never attempt to<br>
> release objects on my own, but I always leave it up to the gc.<br>
> Even in that case a segfault is indeed possible and that's why we
need<br>
> to open an issue on bugzilla so that the developers know.<br>
> <br>
> quote/<br>
> <br>
> So my suggestion is: do not use delete at all, since the jvm will<br>
> handle that for you automatically, but remember that this will not<br>
> prevent random crashes from happening. The issue is unfortunately<br>
> deeply rooted within mapserver, which was not coded for long<br>
> multi-threaded operations, but rather for short-lived independent<br>
> processes.<br>
> <br>
> To date I have found that Java mapscript can be used to provide basic<br>
> mapping services with reasonable stability and performance when only<br>
> the following components are involved:<br>
> <br>
> - shape support<br>
> - raster support (via gdal)<br>
> - proj<br>
> <br>
> In the future I will have to support postgis and that frankly worries
me a bit.<br>
> <br>
> HTH,<br>
> Umberto<br>
> <br>
> > Regards.<br>
> ><br>
> > ------------------------------------------------------------------------<br>
> > Fernando Simon<br>
> > Mapserver and Oracle Spatial developer<br>
> > G10 - Laboratorio de Computacao Aplicada - Brazil<br>
> > http://www.univali.br/g10 - UNIVALI/CTTMAR<br>
> > ------------------------------------------------------------------------<br>
> ><br>
> > Benedikt Rothe wrote:<br>
> ><br>
> > ><br>
> > > Hallo Umberto and Christian<br>
> > ><br>
> > > Christian reported a crash in layerObj.delete() which I<br>
> > > also detected.<br>
> > > I think I understood the following:<br>
> > ><br>
> > > Let's say, we have an initialized mapObj mO;<br>
> > ><br>
> > > layerObj lO = new layerObj(mO);<br>
> > > // Say lO is the 5th layer now.<br>
> > > // Now lO.swigCMemOwn == true and<br>
> > > // lO.swigCPtr points onto the mO.swigCPtr->layers[4]<br>
> > ><br>
> > > ...<br>
> > > // now the mapObj is deleted but the Java-layerObj continues
to live.<br>
> > > // the C-layer-Object mO.swigCPtr->layers[4] will deleted
and freed also!<br>
> > > mO.delete()<br>
> > > // From now on O.swigCPtr points into invalid piece of C-memory.<br>
> > > ...<br>
> > ><br>
> > > Later on the Java-garbage-collector finalizes the layerObj.<br>
> > ><br>
> > > Because of "lO.swigCMemOwn == true" and "lO.swigCPtr!=0"
the<br>
> > > finalize-method calls<br>
> > > layerObj.delete(). This method frees lO.swigCPtr which is
invalid memory.<br>
> > ><br>
> > > Same story about layerObj/classObj.<br>
> > ><br>
> > > Benedikt Rothe<br>
> > ><br>
> > ><br>
> > ><br>
> > > UMN MapServer Users List <MAPSERVER-USERS@LISTS.UMN.EDU>
schrieb am<br>
> > > 28.06.2005 12:16:01:<br>
> > ><br>
> > > > Hello Umberto,<br>
> > > ><br>
> > > > Umberto Nicoletti wrote:<br>
> > > ><br>
> > > > >Hi Christian,<br>
> > > > >I do not think the error you are getting is due
to threading issues,<br>
> > > > >but trying what Mario suggests will at least narrow
the search field.<br>
> > > > ><br>
> > > > >In case you are still getting errors even with
synchronized code<br>
> > > > >blocks I have a few questions for you to help me
understand your<br>
> > > > >setup:<br>
> > > > >Do you always get errors in delete_classObj or
do the segfaults happen<br>
> > > > >in different functions?<br>
> > > > ><br>
> > > > ><br>
> > > > Yes, the segfaults alway happen in the delete_classObj
function.<br>
> > > ><br>
> > > > >If the segfault is always caused by<br>
> > > > >delete_ClassObj then I suppose you are creating
class objects in your<br>
> > > > >java code. Is that true?<br>
> > > > ><br>
> > > > ><br>
> > > > Yes, that's true, I need to create classObjects.<br>
> > > ><br>
> > > > >If that is the case then we can setup a very simple
test to reproduce<br>
> > > > >the problem: modify one of the examples so that
it will load a map and<br>
> > > > >then start adding classes in similar fashion to
your code, but in a<br>
> > > > >tight loop. Classes should be made eligible for
gc by dropping all<br>
> > > > >references to them. As soon as gc kicks in the
vm should crash. At<br>
> > > > >that point it will be clear that the problem is
in delete_ClassObj and<br>
> > > > >the hunting season will be open.<br>
> > > > ><br>
> > > > ><br>
> > > > I have tested a proposed solution by Benedikt Rothe
yet, which said that<br>
> > > > one should call the delete method of the classObject
after it is not<br>
> > > > needed any more.<br>
> > > > This confirms my assumption that this problem occours
when java's<br>
> > > > garbage-collector destroys the null-referenced objects.
Now it seems to<br>
> > > > work properly.<br>
> > > ><br>
> > > > The mapserver version we actually use is 4.4.1, we
have tested 4.4.2,<br>
> > > > 4.2.4 and 4.6.0, too before.<br>
> > > ><br>
> > > > Thank you all for your help!<br>
> > > ><br>
> > > > Best Regards,<br>
> > > > Christian :-)<br>
> > > ><br>
> > > ><br>
> > > > >BTW can you report the mapserver version you are
using (I have 4.4.2<br>
> > > > >and I know it works, so if you can use that).<br>
> > > > ><br>
> > > > >Best Regards,<br>
> > > > >Umberto<br>
> > > > ><br>
> > > > >On 6/21/05, Christian Schroeder <mailings@abiwood99.de>
wrote:<br>
> > > > ><br>
> > > > ><br>
> > > > >>Hello Umberto,<br>
> > > > >><br>
> > > > >>thank your for your immediate answer.<br>
> > > > >>I do not call the delete_ methody directly
and don't think I am using<br>
> > > > >>special gc parameters.<br>
> > > > >><br>
> > > > >>And... I have read the README file before compiling
the mapserver :-)<br>
> > > > >><br>
> > > > >>I will try to get it to work with "synchronized"-flags
als Mario Basa<br>
> > > > >>supposed.<br>
> > > > >><br>
> > > > >>Thank you!<br>
> > > > >><br>
> > > > >>Christian<br>
> > > > >><br>
> > > > >><br>
> > > > >>Umberto Nicoletti schrieb:<br>
> > > > >><br>
> > > > >><br>
> > > > >><br>
> > > > >>>Christian,<br>
> > > > >>>are you calling the delete_ methods directly
in your code or are you<br>
> > > > >>>using some special gc paramaters?<br>
> > > > >>><br>
> > > > >>>As a side note the --use-threads option
to configure is *absolutely*<br>
> > > > >>>necessary, as are brakes on your car. I
think we should write it in<br>
> > > > >>>the README (as if someone actually cared
to read it :-( ).<br>
> > > > >>><br>
> > > > >>>Best regards,<br>
> > > > >>>Umberto<br>
> > > > >>><br>
> > > > >>><br>
> > > > >>>On 6/21/05, Sean Gillies <sgillies@frii.com>
wrote:<br>
> > > > >>><br>
> > > > >>><br>
> > > > >>><br>
> > > > >>><br>
> > > > >>>>I'm forwarding this to the users list.
Hopefully, Umberto will<br>
> > > be able<br>
> > > > >>>>to provide some insight.<br>
> > > > >>>><br>
> > > > >>>>cheers,<br>
> > > > >>>>Sean<br>
> > > > >>>><br>
> > > > >>>>On Jun 16, 2005, at 5:08 PM, Christian
Schröder wrote:<br>
> > > > >>>><br>
> > > > >>>><br>
> > > > >>>><br>
> > > > >>>><br>
> > > > >>>><br>
> > > > >>>>>Dear Mr. Gillies,<br>
> > > > >>>>><br>
> > > > >>>>>some weeks ago me and Florian Pepping
contacted you because we had<br>
> > > > >>>>>problems using the Java Mapscript
API. Thanks to you we could solve<br>
> > > > >>>>>these problems :-)<br>
> > > > >>>>><br>
> > > > >>>>>Now we got our program doing what
it's supposed to do but there is<br>
> > > > >>>>>still a big problem left which
we were not able to solve yet:<br>
> > > > >>>>>We created a simple servlet which
is created inside a Tomcat 5.0<br>
> > > > >>>>>Webserver. This servlet created
a map image (png/jpg) and displays<br>
> > > > >>>>>some specified objects on the map.
(We use it for location based<br>
> > > > >>>>>services --> "show me the
position of the next printer").<br>
> > > > >>>>>After an irregular number of calls
of our servlet which uses<br>
> > > the Java<br>
> > > > >>>>>Mapscript API the complete Java
VM and with it the Tomcat<br>
> > > crashes. I<br>
> > > > >>>>>attached the error report below.
The program works properly for a<br>
> > > > >>>>>number of calls (between 5 and
1000 :-) ) and after that it<br>
> > > crashes.<br>
> > > > >>>>>We have tried several versions
of the mapserver (4.4.1, 4.4.2,<br>
> > > 4.2.4,<br>
> > > > >>>>>4.6.1 RC1) and compiled the Java
Mapscript Module with JDK<br>
> > > 1.4.2 and<br>
> > > > >>>>>1.5.0. We also configured mapserver
using the --with-threads<br>
> > > option,<br>
> > > > >>>>>but all this did not help. By the
way the mapserv cgi-module works<br>
> > > > >>>>>properly.<br>
> > > > >>>>><br>
> > > > >>>>>Do you have an idea for this?<br>
> > > > >>>>><br>
> > > > >>>>>Thanks for your anxiety<br>
> > > > >>>>><br>
> > > > >>>>>Christian & Florian<br>
> > > > >>>>>University of Paderborn, Germany<br>
> > > > >>>>><br>
> > > > >>>>><br>
> > > > >>>>>-------------------------------------------------------------------<br>
> > > > >>>>><br>
> > > > >>>>>JavaMapscriptLoader: mapscript
native library has been loaded.<br>
> > > > >>>>>* mapscript native library loaded
*<br>
> > > > >>>>><br>
> > > > >>>>>An unexpected exception has been
detected in native code<br>
> > > outside the<br>
> > > > >>>>>VM.<br>
> > > > >>>>>Unexpected Signal : 11 occurred
at PC=0x3338268<br>
> > > > >>>>>Function=delete_classObj+0x8<br>
> > > > >>>>>Library=/usr/lib/libmapscript.so<br>
> > > > >>>>><br>
> > > > >>>>>Current Java thread:<br>
> > > > >>>>> at edu.umn.gis.mapscript.mapscriptJNI.delete_classObj(Native<br>
> > > > >>>>>Method)<br>
> > > > >>>>> at edu.umn.gis.mapscript.classObj.delete(classObj.java:32)<br>
> > > > >>>>> at edu.umn.gis.mapscript.classObj.finalize(classObj.java:26)<br>
> > > > >>>>> at java.lang.ref.Finalizer.invokeFinalizeMethod(Native<br>
> > > Method)<br>
> > > > >>>>> at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)<br>
> > > > >>>>> at java.lang.ref.Finalizer.access$100(Finalizer.java:14)<br>
> > > > >>>>> at<br>
> > > > >>>>>java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)<br>
> > > > >>>>><br>
> > > > >>>>>Dynamic libraries:<br>
> > > > >>>>>Can not get information for pid
= 10558<br>
> > > > >>>>><br>
> > > > >>>>>Heap at VM Abort:<br>
> > > > >>>>>Heap<br>
> > > > >>>>>def new generation total
1152K, used 135K [0x08ae0000,<br>
> > > 0x08c20000,<br>
> > > > >>>>>0x08fc0000)<br>
> > > > >>>>> eden space 1024K, 0% used
[0x08ae0000, 0x08ae4078, 0x08be0000)<br>
> > > > >>>>> from space 128K, 100% used [0x08c00000,
0x08c20000, 0x08c20000)<br>
> > > > >>>>> to space 128K, 0%
used [0x08be0000, 0x08be0000, 0x08c00000)<br>
> > > > >>>>>tenured generation total
15048K, used 13624K [0x08fc0000,<br>
> > > > >>>>>0x09e72000,<br>
> > > > >>>>>0x0cae0000)<br>
> > > > >>>>> the space 15048K, 90%
used [0x08fc0000, 0x09d0e1c0, 0x09d0e200,<br>
> > > > >>>>>0x09e72000)<br>
> > > > >>>>>compacting perm gen total
18432K, used 18373K [0x0cae0000,<br>
> > > > >>>>>0x0dce0000,<br>
> > > > >>>>>0x10ae0000)<br>
> > > > >>>>> the space 18432K, 99%
used [0x0cae0000, 0x0dcd1618, 0x0dcd1800,<br>
> > > > >>>>>0x0dce0000)<br>
> > > > >>>>><br>
> > > > >>>>>Local Time = Tue Jun 14 15:32:19
2005<br>
> > > > >>>>>Elapsed Time = 246<br>
> > > > >>>>>#<br>
> > > > >>>>># The exception above was detected
in native code outside the VM<br>
> > > > >>>>>#<br>
> > > > >>>>># Java VM: Java HotSpot(TM) Client
VM (1.4.2_08-b03 mixed mode)<br>
> > > > >>>>>#<br>
> > > > >>>>># An error report file has been
saved as /tmp/hs_err_pid10558.log.<br>
> > > > >>>>># Please refer to the file for
further information.<br>
> > > > >>>>>#<br>
> > > > >>>>><br>
> > > > >>>>>-------------------------------------------------------------------<br>
> > > > >>>>><br>
> > > > >>>>>On Mar 22, 2005, at 12:02 PM, Florian
Pepping wrote:<br>
> > > > >>>>><br>
> > > > >>>>><br>
> > > > >>>>><br>
> > > > >>>>><br>
> > > > >>>>><br>
> > > > >>>>>>Dear Mr. Gillies,<br>
> > > > >>>>>><br>
> > > > >>>>>>I'm a student of the University
of Paderborn in Germany and<br>
> > > member of<br>
> > > > >>>>>>the project group "Location
Based Services for Wireless<br>
> > > Devices". In<br>
> > > > >>>>>>this project we try to position
laptops and other WLAN-enabled<br>
> > > > >>>>>>devices using the signal
strength of the WLAN. According to their<br>
> > > > >>>>>>position, we want to
offer location based services to the persons<br>
> > > > >>>>>>using the devices (where
I am; where's the next printer; is<br>
> > > there a<br>
> > > > >>>>>>friend nearby)<br>
> > > > >>>>>><br>
> > > > >>>>>>In order to do this, we want
to use your mapserver and the Java<br>
> > > > >>>>>>Mapscript API to generate maps
according to the actual<br>
> > > position and<br>
> > > > >>>>>>situation. We like to customize
the map of our building and add<br>
> > > > >>>>>>points, lines and so on.<br>
> > > > >>>>>><br>
> > > > >>>>>>We have been able to compile
the whole mapserver and the Java<br>
> > > > >>>>>>Mapscript API. A small Java
example also works, which presents an<br>
> > > > >>>>>>unchanged map of our building.<br>
> > > > >>>>>><br>
> > > > >>>>>>[...]<br>
> > > > >>>>>><br>
> > > > >>>>>><br>
> > > > >>>>>><br>
> > > > >>>>>><br>
> > > > >>><br>
> > > > >>><br>
> > > > >>><br>
> > > > >>><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> ><br>
> ><br>
> ><br>
</tt></font>