On 12 February 2010 16:43, Carl <c...@etrak-plus.com> wrote: > 1. There is no place in the code that we intentionally put an exit(). I > have grepped for exit() and found nothing. The system stops in a different > place every time... the last entry in catalina.out has never been the same > (over 15-20 failures.)
I'm wondering about a concurrency issue, given that the failure occurs more frequently under load but can occur at other times. But it's difficult to think of one that would cause a silent crash like this, unless you're using a library somewhere that makes use of the "crash and burn" school of error handling! ... actually, that's a thought. There *is* a way of you distinguishing the VM exiting in an orderly fashion, quitting, or being terminated, and that's to add a tiny webapp that just registers a shutdown hook (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook%28java.lang.Thread%29). If you're willing to add that debug code, then you could log a message (or simply touch a file). If there's no message/file, the VM is shutting down due to an error or someone's calling halt (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#halt%28int%29). As another small piece of debugging, it would be very interesting to capture the exit status of the JVM. How are you starting it, and is there any chance of inspecting the code on exit? A non-zero exit code, in particular, would be interesting. As a third, rather larger, piece of debugging, you could consider running Tomcat under a security manager that allowed all operations except exit. This may be tough to get right, especially on a production server, but it would definitely tell you whether there were any Java calls to Runtime.exit() or Runtime.halt(). Finally, is there any native code in any part of your application? This is, of course, outside of any of the JVM handlers; a failure of native code can (and occasionally does!) cause mayhem. None of this is a solution, I'm afraid. It's all just more debugging and gathering more information. But the problem is sufficiently unusual that I think you're going to have to keep on debugging it :-(. - Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
