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 27371] - java.lang.ThreadDeath caused by log4j when reloading Tomcat app
Date Wed, 09 Nov 2005 20:17: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=27371>.
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=27371





------- Additional Comments From darryl@darrylmiles.org  2005-11-09 21:17 -------
(In reply to comment #45)
I request a reload of the webapp, Tomcat's manager fails the reload
> operation and indicates a ThreadDeath has occured. I fully expect the request to
> get ThreadDeath if it continues running beyond the scope of a context reload but
> what I am seeing (and I consider this a bug) is Tomcat dishing out a ThreadDeath
> to a completely unrelated request. If I try sending out request #2 after the
> reload operation returns ThreadDeath, the request will fail with yet another
> exception. From this point onward Tomcat is in some sort of bad state and no
> matter how many times I try manager stop/start/reload it'll always fail. I am
> forced to fully shutdown Tomcat and restart it. New requests to the webapp now
work.


The annoyance I get is that Tomcat states the ThreadDeath that occurs wont upset
the re-deployed web-app, but it does.  No further requests to tomcat on the
web-app are possible.  The only way out is a container restart.  I think maybe
this is a genuine different problem but I've no proof yet.


Maybe as a helpful suggestion, Tomcat could emit in the ThreadDeath exception
message the Thread.getId() and Thread.getName() of the thread that is dying,
this would be useful anyway to help fix your application and put us developers
in the picture as to exactly what died.

throw new java.lang.ThreadDeath("of
Thread#"+Thread.currentThread().getThreadId()+" "+Thread.currentThread().getName());

Would such a trival patch be accepted ?


Unfortunatly I've had no time this week to investigate further, I'm eyeing up
hacking on JMP (Java Profiler) to get a class loader report from heap snapshots
then dumping out all references between objects that cross to a different class
loader.  Maybe someone knows of a tool already for this ?

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

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


Mime
View raw message