[mapserver] Java VM Crashes using the Mapscript API

[Umberto Nicoletti]

gmail messed up big time!

My reply again:

On 11/18/05, umn-ms at hydrotec.de <umn-ms at hydrotec.de> wrote:
>
> Hallo Umberto, Fernando, Donovan and ...
>
> Thanks for coming back to this point. This area is also still a big
> problem to me. (Especially I'm happy about the Java/Oracle-guru-combination
> Fernando/Umberto.)
>

You are overrating me (blushing)

> It's maybe usefull to figure out where we agree and where we disagree:
>
> - I disagree to Umberto with the use of the Java-gc in Mapserver 4.6. I
> state:
>   As long as Java/Mapserver is at is is now (Version 4.6.1)
>   one must not rely on gc only. One has to call delete.

I should have pointed out that I was talking about 4.4.2.
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.
I have performed extensive profiling (in terms of both concurrent
users and elapsed time) for my apps and memory was efficiently managed
by the VM with no leaks and this convinced me further not to call
delete.

>   To the question of Fernando: "So the question is, where I can call delete?
> "
>   is my rule of thumb:
>    "Call delete on Mapserver-Objects as soon as you can whenever a delete
> exists."
>
>   As a matter of fact: By doing so, delete is called more often then
> necessary, because
>   in many cases the finaliser would do a good job.  But this doesn't matter.
>

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.

> - I  agree to Umberto that there is a bug in Java/Mapserver behaviour.
>   My suggestion is obvioulsy not a solution but a way to live with
>   the software as it is.
>

Which is what we do with most software anyway ;-)

> If we would come to the question "How should Java/Mapserver behave"
> my personal opinion is to look at the way the Eclipse-People made SWT.
> They also had the problem, that Java-Objects enclose ressources which are
> not managed by the Java-VM:
> http://www.eclipse.org/articles/swt-design-2/swt-design-2.html
> (Rule 1: If you created it, you dispose it. )
> Following this approache would leave to only small changes in
> Java/Mapserver-Code
> but to a different documentation of the Java/Mapscript-API and it should be
> clearer
> when a objected has to be delete by the way an object is created.
> (Actually I suppose, that Umberto will disagree in this point  ...  :-) )
>

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.
-all delete methods should be implemented so that they are smart
enough check for null pointers before dereferencing them, to avoid npe
in the gc phase.
- finally there is the enormous problem of global variables in
mapserver sources which make some of it not thread safe.

For the record: I would *love* to be proved wrong and get in exchange
a reasonably safe Java mapscript, even without all whistles and bells
of a mapserver cgi.

> At last it's maybe usefull to share experiences in stability:
> We wrote an Oracle-Spatial/Tomcat/Mapserver-Application
> (Linux-Suse 9.3)
> - On our testsystem it runs very fine for weeks.
>   The testsystem even survives stress-tests, where we simulate some browsers
> making
>   many requests.
> - On the customers (production-)machine we still have Tomcat crashes about
> one or
>    two times the day. We didn't find a solution (except a watchdog-software
> which restarts tomcat in
>    the crash-case :-( )
>    This machine also survives the one- or two-hour stress-tests!
>
> This happens although I'm quite shure, that we followed the "delete as soon
> as possible"-rule.

BTW: how do you stress test your application (software, configuration, etc)?

Best regards,
Umberto