We should register a Thread.UncaughtExceptionHandler. When there is an uncaught exception, the handler should

• log the exception,
• restart the corresponding thread if possible,
• shutdown the server if necessary.

And/or ensure (via code review) that Thread and Runnable classes catch and handle Throwable exceptions properly.

I dont think JVM shutdown is an action that should be taken by a handler, as it is making assumptions about how the process is running that may not always hold. It will certainly make a mess of JUnit tests, for example.

How about we identify wherever threads get used and make sure that exceptions get caught and reported. In my codebase we have replaced Runnable with an interface that throws things

public interface Executable

There is a matching thread class that implements this and calls any implementation it is bonded to; threads are caught and a notification object called. This lets us catch everything and listen for problems.

public void run() {
try

catch (Throwable throwable)

finally {
synchronized (notifyObject)

}
}

If the services aren't catching failures, it also means they are probably leaking threads. Not good for extended use.

I'd be happier with

• something like the code above
• every thread to have a useful toString() override
• the UncaughtExceptionHandler only logs the uncaught exception at ERROR level, with the relevant toString(). The error message should tell the viewer to log a bugrep on apache jira

Alternatively: use the java5 concurrency stuff instead of threads.

Alternatively: use the java5 concurrency stuff instead of threads.

+1

Callable is almost equivalent to your Executable interface.

so it is. +1 to using it, adding handlers for failures that log and retain errors, report to hosting services

This probably needs to get revisited.... so PING!