Alexander Leykekh wrote:
Does JVM loose ability to intercept termination signals by having been initialized in a separate thread? I.e., does above suggestion mean AOLserver will intercept SIGTERM, but whatever TERM handler was potentially established by JVM will not fire?
I work on JK2 module which runs Jakarta/Tomcat in-process. Somehow I don't see evidence of JVM shutting down with AOLserver when I trace the process in debugger. I wonder if that is due to separate-thread initialization of JVM. Does anyone have insight on this?
You can use Ns_RegisterShutdown to register a proc to be called. In the nsjava module I do a cond wait at the end of the jvm startup thread, and I use the registered shutdown proc to signal the jvm thread to exit. I used to also destroy the jvm before exiting the jvm thread, but I no longer do so due to some irregularities between different jvm vendors. You could use something similar to shutdown the your jvm.
Approaching the same issue from a different angle, does it even matter that explicit JVM shutdown doesn't happen? It would if there were such a thing as "shutdown servlet", which I don't see in servlets standard. Am I correct here? I did try the case where JVM was initialized from AOLserver's main thread. No apparent negative effect, including garbage collection problems (I conducted a load test and saw no evindence of memory leak, which is how garbage collection problem would manifest itself).
Actually the problem wasn't that the garbage collector wouldn't run, but rather the problem was that the garbage collector thread wouldn't wake up after running due to the wake-up signal being blocked by aolserver. In my testing, I found it was necessary to create a large number of objects before the garbage collector was triggered. Another thing to consider is that various jdk vendors may implement garbage collection differently, so you need to test with a variety of jdk vendors to ensure that everything is functioning correctly. Dan
