tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ofer Israeli <>
Subject RE: Bug in Tomcat AJP Connector?
Date Sun, 08 Apr 2012 16:41:38 GMT
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?


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

View raw message