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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
