Although some of the main problems with leaks in the Event callback parts have been eliminated, still there remain a few problems, of which it is unsure whether they be located within jacob code or within JNI itself.
Observation and experiments support the thesis that JNI produces memory leaks on external thread attach/detach sequences. On our production code that under certain circumstances makes millions of callbacks per day, this meant we had to restart the program approximately
- every 5 hours before the jacob bugfixes
- every 5 days after the latest jacob bugfixes
due to out of heap space conditions.
To circumvent this, we rewrote the event callback part to contain a tcp/ip communication layer instead of JNI thread attach/detach sequences.
Without any further change, our program can run for a week without any noticeable increase of java heap. We haven't tried but assume it could run for months if not years without restart now without reaching out-of-heapspace conditions (which is a requirement for our program).
The good thing: The API remains almost unchanged. Per default, the old callback scheme is used, so if we did not accidentally break something (which should then be easy to fix), any existing code should work as before, with the existing leaks of course. The Java-to-C direction code is completely unchanged.
The bad thing: if you want to use the new tcp/ip scheme, you lose the ability of returning values from the client's callback routines. If you need such things (we didn't), you would have to extend the tcp/ip layer to be able to communicate bidirectionally. This should be possible, but maybe not as simple as what we did right now.
The other bad thing: since for the sake of simplicity we communicate XML strings over tcp/ip, this slows down callbacks a little bit, and you need the jdom xml parser library on the java side. Constructing the xml strings in C(++) is done with simple string operations, so no external library is needed there.
We hope this is of any use for the jacob community, at least for those who heavily want to use callbacks.