-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 11/1/14 8:59 AM, Konstantin Kolinko wrote:
2014-11-01 3:57 GMT+03:00 Campbell, Lance la...@illinois.edu:
Tomcat 7.0.56
Java 7.0_72
I received the below Tomcat error messages in a web application.
Is there a way for me to catch these exceptions so that I can
then either execute Java code or trigger a Linux shell script?
Oct 31, 2014 7:38:25 PM
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor doRun
SEVERE:
java.lang.OutOfMemoryError: Java heap space
Oct 31, 2014 7:38:46 PM
org.apache.tomcat.util.net.NioEndpoint$Acceptor run
SEVERE:
java.lang.OutOfMemoryError: Java heap space
Oct 31, 2014 7:38:49 PM
org.apache.tomcat.util.net.NioEndpoint$Poller run
Thanks,
There is a family of options such as -XX:OnOutOfMemoryError,
-XX:+HeapDumpOnOutOfMemoryError in Oracle Java. The first one is
used to launch an external script in case of OOM.
Doing anything from Java rarely works in case of an OOM error,
especially a PermGen OOM. (You have a bit more luck with your
Java heap space one).
See http://markmail.org/message/rr26epg4oap4syus Notification
strategy for OutOfMemoryError thread from about a year ago.
+1
My experience is that, of the options available, the
- -XX:OnOutOfMemoryError option is the most reliable.
However.
Since I've been using that technique, there have been plenty of times
where I've found an OOME condition (shown in catalina.out, for
instance) and the JVM has actually not executed my external script.
YMMV
I've also implemented a Filter that catches OutOfMemoryError and
attempts to log the condition. I have very little data about how often
it actually runs, but it definitely does run sometimes: it helped us
find a runaway-search bug that happened in a mundane part of our web
application, because we were able to see the query string being sent
by the remote user.
The Filter basically just wraps a try/catch block around
chain.doFilter(...) with this as the exception handler:
catch (OutOfMemoryError oome)
{
logger.error(Detected OutOfMemory condition during request);
logger.error(Here are some request details:);
logger.error(Next line will contain the current request's
URI);
logger.error(request.getRequestURI());
logger.error(Next line will contain the current request's
query string (if any):);
logger.error(request.getQueryString());
logger.error(Next line will contain the original
request's URI (essentially what the client actually requested));
logger.error(request.getAttribute(javax.servlet.forward.request_uri));
logger.error(Next line will contain the original
request's query string (if any):);
logger.error(request.getAttribute(javax.servlet.forward.query_string));
logger.error(Finally, the current user (if any):);
logger.error((null != request.getSession(false)
null !=
request.getSession(false).getAttribute(user)
? request.getSession(false).getAttribute(user)
: no current user));
_application.setAttribute(OOME_KEY, Boolean.TRUE);
throw oome;
}
Note that, other that whatever overhead the logger itself adds, there
are no memory allocations that occur in the exception handler itself.
Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUVWkXAAoJEBzwKT+lPKRYvB4P/3WdCT2RZ5cc32vnLGelOURw
pxFq5QJeNLru6elAStNOJPuWVJ3m4lmK45juhdrMKJp69fuB+bK7raUF7Ekc3ISh
1s7GGb9S0McKuI8Hfrdzp/NzGMdbMDCGJZzqyEqqeuRrKCZ5F2SRwD1mbT59gIr0
Tqe69CsmAmWnIq47iCV++KhPvmwEnROwTrbjjIXi3UpdYskEtnX8tHPAFWHZZZrj
3bVSPH7UokoBMkAja4nM8hYpHK+7f8lGHve98EQlTi6oU00Cfv6w9VhMZ9N0WfE+
T/f7+OgGyD4gkQ/pReebd4ri1aPyBApfnk4ApgFA3/g057u5scsV+zKIsWxycllF
f6Eo6RS8zaAbcaX1mUmF9XgdyV49WYW+lkbF2NmqQRBqe4C4mXRa4pgGzTLauBcD
/EmPvgZCluTDiV4pzshEtHmzEXKptzIPs5oRWswmKZcxntKeUi8hW6/QIlzGl8PV
f1VCX3/j/qUBo2rzZird3KJd7thTgdl0SLLlapMCP8LFoiMxm4q2urQdT9G/sWxR
u7jYgfbSAUM6Wn3Z0XA2yc9BEFIbrOEUwYQYkJ3Zw4jbLTWqdIiYw0bgEkBlzewF
JRJUU75jvJE27qto6iBvIWdvTh66gtHNpQw2nXN4LLEdVMvSI+77f7AsDgILT67x
d0lLQjlmlIwIGOxFW7nD
=LN4V
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
