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 26372] - java.lang.ThreadDeath when trying to reload an application
Date Thu, 08 Dec 2005 15:11:33 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=26372>.
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=26372





------- Additional Comments From bugzilla-asf@dm.cobite.com  2005-12-08 16:11 -------
i think i know how to reproduce and prevent this error.  assistance from the
tomcat developers could enhance the workaround.

the problem (for me) seems to stem from bad commons-logging interaction.  the
commons-logging that the container uses to log errors from my context ends up
discovering the commons-logging.jar and log4j.jar that I have put in my
WEB-APP/lib.  the container ends up with instances of classes loaded by the
WebAppClassloader associated with the initial instance (initial start cycle) of
the webapp.  when reload happens, that classloader becomes invalid, and any
further classloading that is attempted through it will cause ThreadDeath.

However, any classes previously loaded are (apparently) still OK.  so the main
cause of ThreadDeath can be avoided if all the classes that need to be loaded
are loaded while the initial WebAppClassloader is still valid (i.e. before the
first reload).  

the easiest way to force all the classes to load is to LOG A MESSAGE from the
appropriate context.  until a message has been logged, not all classes in the
logging 'execution path' will have been accessed, and so there will be some
class loading that happens during the first logged message.  after that, that
execution path will be 'loaded' and can run till the cows come home.

for me, the easiest thing to do is force a JSP error. maybe have a JSP called
cant_compile.jsp, and hit it as soon as you start up tomcat.  then you will have
NO problems until you shutdown tomcat again.

an easy solution not requiring any changes at all is to put:

log4j.logger.org.apache.catalina.session=DEBUG

into log4j.properties.  you will not get TOO much debug crapola in your logs
(about 15 lines on startup/shutdown).

here's where the tomcat developers come in.  if tomcat logged something as soon
as startup is complete - AT A SUFFICIENTLY HIGH LOGGING LEVEL (eg info) that it
will be feasible to have logging enabled at that level. 

in particular, changing the debug statement at line 655 of StandardManager.java
to info seems a likely candidate.

then users could set (in log4j.properties or equiv):

log4j.logger.org.apache.catalina.session=INFO

and not get superfluous debugging statements.




-- 
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