Bug 36250 - Tomcat should not return FAIL on ThreadDeath during redeploy
Tomcat should not return FAIL on ThreadDeath during redeploy
Status: RESOLVED DUPLICATE of bug 26372
Product: Tomcat 5
Classification: Unclassified
Component: Unknown
5.5.7
PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-08-18 17:11 UTC by Gili
Modified: 2005-12-10 07:56 UTC (History)
4 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gili 2005-08-18 17:11:44 UTC
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".
Comment 1 Remy Maucherat 2005-08-18 19:21:47 UTC

*** This bug has been marked as a duplicate of 26372 ***
Comment 2 Gili 2005-08-18 19:33:53 UTC
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.
Comment 3 Ralf Ebert 2005-08-20 22:36:49 UTC
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.
Comment 4 Gili 2005-08-20 22:41:52 UTC
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.
Comment 5 Gili 2005-08-22 18:00:46 UTC
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.
Comment 6 Remy Maucherat 2005-08-22 18:24:56 UTC

*** This bug has been marked as a duplicate of 26372 ***
Comment 7 sherold 2005-09-12 16:27:39 UTC
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.
Comment 8 Remy Maucherat 2005-09-12 16:34:53 UTC

*** This bug has been marked as a duplicate of 26372 ***
Comment 9 Karel Zikmund 2005-09-12 16:38:57 UTC
Marked as duplicate by mistake - because there's no explanation.
Comment 10 Remy Maucherat 2005-09-12 16:41:17 UTC

*** This bug has been marked as a duplicate of 26372 ***
Comment 11 Remy Maucherat 2005-09-12 16:44:47 UTC
(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.
Comment 12 Gili 2005-09-12 16:51:53 UTC
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? :)
Comment 13 Remy Maucherat 2005-09-12 17:11:28 UTC
(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.
Comment 14 Darryl Miles 2005-12-10 16:56:22 UTC
(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 :)