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 [EMAIL PROTECTED],
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
