tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 36250] - Tomcat should not return FAIL on ThreadDeath during redeploy
Date Sat, 10 Dec 2005 15:56:23 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=36250>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36250


darryl@darrylmiles.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darryl@darrylmiles.org




------- Additional Comments From darryl@darrylmiles.org  2005-12-10 16:56 -------
(In reply to comment #12)
> Maybe I should restate this another way for Remy...
> 
> Let A = "Tomcat should not return FAIL if this classloading problem occurs"
>     B = "Tomcat should recover from this classloading problem"
> 
> Now bear with me.... A != B
> How come everyone CCed on this issue understands this except you? :)

"A" do you mean that Tomcat fails completely after a ThreadDeath ?

My own findings when a ThreadDeath error message occurs, even though in the
message it says this error is okay, tomcat is still okay, all is right in the
world, this is infact not the case.

>From the point the ThreadDeath occur the web-app for which it related to no
longer works, can no longer be reloaded, will no longer accept HTTP requests. 
The only way out is a container restart.


I would agree with Remy if the ThreadDeath had occured in relation to Tomcat's
internal code.  But these thread death's occur from executing web-app related
code and I think its possible for the container to be robust enough to recover
from that.


What if we created a TomcatWepappClassLoaderError sub-class of java.lang.Error,
which could store and pass back ThreadId, ThreadName, StackTrace, ClassForName
being loaded and override printStackTrack with warning message.

Then in the part of Tomcat internal code that passed control from Tomcat to web-app:

try {
  callWebappContextMethod();
} catch(TomcatWebappClassLoaderError e) {
  // Take defensive action to cleanup, try to keep the thread alive and
terminate normally
  if(weReallyDoWantToKillThisThread) {
    e.printFancyStackDumpToHelpDeveloperFixBug();
    throw new ThreadDeath();
  }
}

But the argument here is that if control can be returned back into tomcat
internal code there is no need for this thread to die in this way, just treat
the situation like regular web-app exceptions, cleanup and keep going.


Now if the thread in question is a background thread started by the web-app,
then it will die without being handled, we want to see a stackTrace and
overloading printStampTrace() function with the warning info gives us a bespoke
dump.

I dont fully understand how this background thread ThreadDeath upsets TC, but I
think it does.

It is possible to setup a ThreadGroup and a defaultUncaughtExceptionHandler,
this must be done before any webapp related code is called (to affect new Thread
creation) this means that during TC startup the initial loading of web-apps
should no longer occur from the "main" thread as it does now, but from a
sub-Thread.  This feels like a good thing to me.

There then should be documentation to assit uses to be TC friendly if they need
to change the uncaughtExcpetionHandler in their code, the initial suggestion
would be to advise the code chains and invokes the default handler it was given
from the container.

These are just thoughts on a way forward at this time, I would prefer if someone
could find a way to shoot them down (so I dont have the implement them :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message