Mark, On 7/14/14, 12:18 PM, Mark Thomas wrote: >> ExceptionUtils.handleException checks for two things that I think >> we might want to change: >> >> 1. If the exception is StackOverflowError, it silently ignores the >> error and continues. I think we should at least log something, >> probably at WARN level. > > No it doesn't. Go and read the code again. The exception is logged at > ERROR level.
Sorry, yes: the StackOverflow is logged.
>> 2. If the exception is VirtualMachineError, it gets re-thrown with
>> no log. This skips the "log" call in the above code and so the only
>> log will come from the VM's "unhandled exception" logger which may
>> not go where you expect it to go.
>
> It goes to stderr unless they system admin has redirected it and if
> they have, they should know where to look for it. Further, they should
> also be monitoring it.
True, but the background thread does die.
>> The exception propagates, and the thread's run() method finishes
>> (escapes due to uncaught exception). After that, regardless of the
>> recoverability of the situation (OOME), the background processor
>> will not run and therefore no auto-reload applications will
>> auto-reload, no sessions will ever die, etc.
>>
>> If we think that StackOverflowError is recoverable, why not
>> OutOfMemory?
>
> There is no assumption that StackOverflowError is recoverable.
public static void handleThrowable(Throwable t) {
if (t instanceof ThreadDeath) {
throw (ThreadDeath) t;
}
if (t instanceof StackOverflowError) {
// Swallow silently - it should be recoverable
return;
}
if (t instanceof VirtualMachineError) {
throw (VirtualMachineError) t;
}
// All other instances of Throwable will be silently swallowed
}
As of April 17, 2014, markt disagrees with you (r1588269):
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/util/ExceptionUtils.java?r1=1588269&r2=1588268&pathrev=1588269
> That is why it is logged at ERROR level.
You are right, StackOverflow gets logged, but things like OOME are not
-- they are left to the unhandled exception handler. But they do
take-down the background thread when they do.
> It is guaranteed that only that
> thread was affected so you know (from the stack trace) exactly what
> failed where and you can also determine how bad things are and opt to
> restart Tomcat if necessary.
For OOME, if you are using sessions you will need to schedule a restart
pretty much immediately, since they will never die.
> With respect to OOME how, exactly, do you propose to differentiate
> between a "recoverable" OOME and a non-recoverable one?
If the admin is monitoring (which we are), then they can make the
determination. The current situation is that Tomcat needs to be bounced
regardless of the severity of the OOME, because the background thread stops.
>> What about other VirtualMachineErrors?
>
> The current position is that they are all non-recoverable. If it can
> be demonstrated that more of them should be treated like StackOverflow
> then we can do so.
Okay. I think OOME should be treated similarly to StackOverflowError.
-chris
signature.asc
Description: OpenPGP digital signature
