To address the issue that has been raised several times on the mailing lists, e.g. http://tomcat.markmail.org/thread/xooxcq56ehki63dh "ContainerBackgroundProcessor and compounding OOMEs" http://tomcat.markmail.org/thread/f6b6vicg7kusckra "Background thread died; no errors in log; invoking backgroundProcess via JMX has no effect" I think it is OK to start a new background thread after some delay. If the start succeeds, it will be a new thread with its own (clean) stack. It may help for StackOverflowError. It might partially help with OutOfMemoryError thread death if nothing else is available, but a better strategy for an admin to handle an OutOfMemoryError is to start JVM with -XX:OnOutOfMemoryError flag with a script that shuts down (and restarts) Tomcat.
Created attachment 31813 [details] 2014-07-15_tc8_56724_v1.patch First version of a patch implementing this feature. The patch is for current trunk (at 1610400).
-1 to adding this feature. If there is a case where an exception triggers the stopping if this thread when it is safe for the thread to be restarted then the fix is to ensure that the thread is not stopped in the first place.
Created attachment 31827 [details] 2014-07-18_tc8_56724_v2.patch Second version. It just adds logging and sets "thread = null;" to allow restarting the thread.
Tested patch v2. The message looks good. Committed in trunk and tc7.0.x. It will be in 8.0.11 and 7.0.55. ( r1611506 r1611509 )
Looking at the code for 9.0.x, 8.5.x and 7.0.x this looks to be complete and has been for a while.