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