Hi, This issue is related to http://issues.apache.org/bugzilla/show_bug.cgi?id=26372 and http://www.netbeans.org/issues/show_bug.cgi?id=62529 I personally consider this issue to be a bug but if you believe it to be a RFE please feel free to modify the severity accordingly. In a nutshell, we're expecting Tomcat to return something other than "FAIL" on a redeploy if a ThreadDeath occurs along the way. Since ThreadDeath does not actually indicate a failure in this case, it would make sense for Tomcat to return something other than "FAIL".
*** This bug has been marked as a duplicate of 26372 ***
Remy... Closing this as DUPLICATE makes no logical sense. I am not complaining that ThreadDeath is occuring (as the original issue does). If you had actually read my full report you would know this. I *understand* why ThreadDeath is occuring. I understand this is normal. I am simply saying that Tomcat should not return FAIL under this condition because as you yourself said in the other discussion thread this is not a failure condition but rather quite normal. So please explain: why is it alright for Tomcat to return FAIL if ThreadDeath is not a failure condition? And also, I have tried all your workarounds mentioned in the other bug report and none of them work so there really is no way to workaround this issue.
I can confirm that the behaviour of Tomcat according to an occuring ThreadDeath feels not correct. After such an failed application reloading, Tomcat should start the application or at least give the possibility to start the application manually. Currently you have to restart Tomcat to get one failed application working again.
I'm tempted to reopen this issue again. Remy has yet to give an explanation for why he considers this issue to be a duplicate.
Remy, I'm reopening this issue because you've not explained why this is a duplicate (and I believe otherwise). I'm not trying to waste your time. I'm honestly interested in your answer. Thank you.
Remy, I'm reopening this issue since it does not seem to me to be a duplicate of issue 26372. The description of this issue says that the tomcat manager should not return FAIL when ThreadDeath occurs, if it is not considered as a real failure.
Marked as duplicate by mistake - because there's no explanation.
(In reply to comment #9) > Marked as duplicate by mistake - because there's no explanation. Explanation: don't be annoying :) More seriously, this error means a classloading problem. No attempt will be made at trying to recover from it. As for its cause and its resolution, it's the same as the bug marked as its duplicate: if you can identify a situation where Tomcat sets bad classloader as context classloader, or similar bad behavior, I will make sure to fix it. This is really trivial logic, and it should be easy to understand without me having to state it in black & white and wasting time. Of course, if you reopen this again, I'll mark it as duplicate again.
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? :)
(In reply to comment #12) > A = "Tomcat should not return FAIL if this classloading problem occurs" Which would be equal to considering this normal. It is not normal, except in the sense that it is to be expected if you do bad things, and is not recoverable. The library, its usage, or whatever else is causing this should be fixed instead. Again, if you can identify a situation where Tomcat sets bad classloaders as context classloader, or similar bad behavior (both which happened in the past, since it's not trivial stuff, unfortunately), I will make sure to fix it.
(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 :)