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 Thu, 27 Oct 2005 08:08:39 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-10-27 10:08 -------
Idea, would it be possible to swap class loaders like a DJ does with Records. 
Let the class loader still exist beyond the contextDestroy() call.  But only for
a limited wall clock time or until the next re-deploy for the same context
(whichever comes first).  We don't want to hold N generations of class loaders
during multiple re-deploys.

I'm not sure if Java allows this, but can a supperior management thread poll all
its child threads (or all threads in the JVM) and enquire details about the
execution context of that thread.  This would allow a background poll of all
threads to occurr to identify which execution threads are still using a class
loader that we are trying to shutdown.  If there are none we can cleanup sooner.

This seems like an obvious need from the JVM given the long running nature of
the JVM and the hierarchical class loader mechanism.

I do understand the servlet spec does not mandate what happens, so what we get
is a bonus to us, but I'm more for the view of lets be a leader and write an
implementation thats robust and useful to the general population then maybe a
specification will be written from it for other implementors follow.  Maybe this
is as odds with TCs boilerplate implementation, but when an issue causes so much
pain to the community its time to bear arms.


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