tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Mayr <>
Subject Re: Bug in Tomcat AJP Connector?
Date Sun, 08 Apr 2012 20:14:20 GMT
Am 08.04.2012 18:41, schrieb Ofer Israeli:
> 2012/4/6 Pid<>:
>> On 05/04/2012 22:17, Ofer Israeli wrote:
>>> Y
>>> On 5 באפר 2012, at 18:58, "Konstantin Kolinko"<>
>> wrote:
>>>> 2012/4/5 Ofer Israeli<>:
>>>>> 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 be
>> restarted.
>>>>>> There is no guarantee of reliable operation after an OOME.
>>>>>> Mark
>>>>> Hi Mark,
>>>>> I agree that there in such a situation the JVM should be restarted, but
>> isn'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 Kolinko
>>> Hi Konstantin,
>>> I agree regarding the OOM bringing TC to a state where it must be
>> restored, 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.
>> p
> Thanks 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:

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message