On 12/11/2013 11:42 PM, André Warnier wrote:
The original issue of the OP was to be notified ASAP when an OOM occurs.
And he indicated that an OOM resulted in a message in the logs.
So, "something" is already catching the OOM exception, to write this line in
the logs.
On the other hand, there is ample literature available that seems to indicate
that any method for trying to recover from (or even do something worthwhile
after) an OOM is ultimately flawed and unreliable.
We have a lot of servlets and JSP's. Most of them do not use huge
amounts of memory but a few do (like reports). When there is a
memory leak, the first thing to get an OOME will be something that
uses a large amount of memory. That request will die, but the rest
of the requests that don't use a lot of memory will have plenty of
space for a while.
I implemented the filter, and it works in my testing. I also implemented
the command line jvm option which works but only gives me the first
OOME. The command line option works no matter what and the
filter works as long as it doesn't run out of memory generating
the email message.
We'll see how it all works after it gets deployed to our production systems
in a few weeks. Our product is mature enough that we've fixed memory
leaks to the point that we normally go many months without any OOME's
so it could be a while before this actually kicks in for a real operating
situation.
Thanks to Christopher for the ideas. They were very helpful.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
