Trustin Lee wrote:
You might encounter segfault due to a bug of the current
implementation because we are using tomcat-native bridge for APR 1.2.
Any feed back is welcome!
The problem is probably with shutting down the APR library.
Tomcat-native is very thin JNI layer for APR, so some
precautions must be taken, like implementing shutdown hooks.
Yes, I found segfault happens when I try to close socket more than once. :)
Right. All native 'objects' are long (actually pointers to the native memory),
and the only check that is done is test for zero (NULL).
It's the same as if you would call free() twice. The second call will probably
core dump cause it references already deallocated memory.
So, although harder to program correctly, it offers zero GC, cause no
Java objects gets created. The same thing is done within core Java (rt.jar)
where actual class implementation takes care of underlaying JNI safety.
I was thinking to add the higher API over this thin layer that would
allow Java programmers to use it more comfortably, but then extra Java
objects would be created, and memory usage as well as GC would rise.
So, when using tomcat-native, think as a C not as Java programmer ;)
Next, the major problem is in threaded environment where you can call
global Pool destroy (shutting down the Library) while there is still native
call in progress.
First thing I would add would be the unlock for Socket.accept
(something each Acceptor, not only APR should have)
and make sure that Socket.close for the acceptor socket is called even
on the CTRL+C. After all native calls are exited, then you can safely
call the Library.shutdown
Regards,
Mladen
