tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Bug in Tomcat AJP Connector?
Date Tue, 10 Apr 2012 15:28:36 GMT
On 09/04/2012 09:18, Ofer Israeli wrote:
> On 08/04/2012 23:14, Stefan Mayr <stefan@mayr-stefan.de> wrote:
>> Am 08.04.2012 18:41, schrieb Ofer Israeli:
>>> 2012/4/6 Pid<pid@pidster.com>:
>>>> On 05/04/2012 22:17, Ofer Israeli wrote:
>>>>> Y
>>>>>
>>>>> On 5 באפר 2012, at 18:58, "Konstantin
>>>>> Kolinko"<knst.kolinko@gmail.com>
>>>> wrote:
>>>>>
>>>>>> 2012/4/5 Ofer Israeli<oferi@checkpoint.com>:
>>>>>>> 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 it
>>>> 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:
>> 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
>>
> Thanks Stefan - will look into this option.

Be careful using that option; if you are also producing a heap dump you
should wait until the heap dump has finished writing before stopping the
process, or the heap will be incomplete & therefore useless.


p


-- 

[key:62590808]


Mime
View raw message