Am 08.04.2012 18:41, schrieb Ofer Israeli:
2012/4/6 Pid<[email protected]>:On 05/04/2012 22:17, Ofer Israeli wrote:YOn 5 באפר 2012, at 18:58, "Konstantin Kolinko"<[email protected]>wrote:2012/4/5 Ofer Israeli<[email protected]>:Mark Thomas wrote:On 04/04/2012 17:02, Ofer Israeli wrote: Once you have an OOME all bets are off. The JVM needs to berestarted.There is no guarantee of reliable operation after an OOME. MarkHi Mark, I agree that there in such a situation the JVM should be restarted, but itisn't restarted by Tomcat. On the other hand, Tomcat does take some precautious actions and kills the accepting thread, but in such a case it should also close the socket that thread is listening on otherwise it is leaving garbage around after the thread's death.Do you see any reason as not to close the listening socket?1. Tomcat does not start JVM thus it cannot restart it. You need some external tool or script or admin to perform monitoring and (re)starts. 2. OOM can happen at a random place. Once it happens, it is likely that other places will also start to fail randomly. It is also likely that your attempts to recover will fail as well. Mark already mentioned it: "all bets are off". Best regards, Konstantin KolinkoHi Konstantin, I agree regarding the OOM bringing TC to a state where it must berestored, but my point remains: if there is code that handles catching this exception and terminating the thread, why not terminate gracefully by closing the listening socket before killing the thread? And your point has been answered. After an OOM the JVM is in an unknown, unsafe state so a restart MUST occur to restore service. Closing a socket gracefully after an OOM is a bit like trying to shut one of the portholes on the Titanic, shortly after hearing a large crashing sound. There's only one place I know of where Tomcat attempts to interact with OOM conditions and this is not one of them, so I don't believe it's safe to say that Tomcat is deliberately handling this exception. NB an OOM is an Error, not an Exception - it is a subclass of VirtualMachineError, which is thrown to indicate that the Java Virtual Machine is broken or has run out of resources necessary for it to continue operating. An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. </end-quote> If anything, the locations where Tomcat catches a Throwable should be modified so it does *not* catch Errors, rather than continuing to do so and then attempting a trivial tidy-up. pThanks for your input - you're right regarding the error and the fact that Tomcat is indeed catching a Throwable and not an Exception. I assume that if the Throwable were not caught, then the thread would die in any case. Although stated before that Tomcat could not kill itself in such a situation, I still wonder if it would be possible to do so. Or taking a different perspective on this: if the JVM specification is such that it cannot be trusted to continue running after an OOM, then why does it not kill itself or restart itself?
I guess you can do this with some vendor specific JVM arguments as SUNs/Oracles -XX:OnOutOfMemoryError: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Different findings like "kill -9 %p" let me suspect that you can use %p as a variable for your current pid. With that you can either kill your current instance and let your monitoring handle the rest or try to initiate the restart by yourself.
Give it a try
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
