tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: OOME crushing tomcat
Date Wed, 10 Oct 2007 07:52:27 GMT
The nature of OOMEs is, that they can happen in every part of the code, 
that needs a new peace of memory. No one is able to write code in a way, 
that can handle memory allocation failures in all places new memory is 
needed.

If you run into an OOME, it is very unwise to let the JVM run along, 
even if it looks OK (only this request got aborted etc.). If the JVM 
needs memory, it tries to free memory. If you get an OOME, it's not 
unlikely, that not only object couldn't get allocated and also it's 
likely, that the OOME will happen again. The failed allocations could be 
in your webapp, in your 3rd party libraries, in the container, in the 
3rd party libs of the container etc.

After an OOME, the behaviour of the whole stack is UNDEFINED. You can't 
even be sure, that the data you deliver is correct!

That's why an OOME usually means you have to restart the JVM. There's no 
stable way to detect, how big the damage is. If you let the JVM run, you 
are taking a huge risk.

All those are true for general Java processes, including Tomcat. There 
are no application controlled allocation pools in Java, such that a 
container can shield itself from the deployed app eating all the memory.

One special case is OOME in Tomcat thread pool. If your load increases 
and Tomcat needs more threads, it could happen that during 
initialization of this thread memory allocation fails and the new thread 
- supposed to take over the network listen fails to get into live and 
you loose your listen on the socket. In this case Tomcat indeed looks 
dead, because the request accepting mechanism got hit by the OOME. In 
this case Tomcat is the victim, not the culprit.

I think there's no sense in making this thread allocation more robust 
(at least as long as we are talking about OOME coming from heap), 
because then the OOME will simply hit some other place with a more 
subtle impact. By my above statements, the immediate impact is not 
relevant, because you can't really control which components are affected 
and need to restart anyways.

Regards,

Rainer

Leon Rosenberg wrote:
> Hi,
> 
> one of my customers recently increased amount of memory they use, so
> OOME are happening more often. Most of them however do no harm, since
> just the request is aborted, but the container remains functional and
> next request wents well (they have a throughput of >100MB per second
> in young generation so chances are good next request will get some
> memory again).
> 
> However, this exception killed tomcat completely (no replies anymore):
> 
> Sep 30, 2007 6:56:51 PM
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable run
> SEVERE: Caught exception (java.lang.OutOfMemoryError: Java heap space)
> executing org.apache.tomcat.util.net.LeaderFollowerWorkerThread@41691942,
> terminating thread
> 
> Any opinions, is that a bug in tomcat or is it inescapable after an OOME?
> 
> regards
> Leon
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message