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 38950] - Problem with WebappClassLoader in background thread
Date Mon, 13 Mar 2006 19:16:26 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=38950>.
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=38950





------- Additional Comments From darryl@darrylmiles.org  2006-03-13 19:16 -------
I have not fully understand and taken in your situation so please forgive me if
I have glossed over some details.  My understanding of Tomcat and ThreadDeath
exception generation is that it occurs when the WebappClassLoader has shutdown
because the Context is was created for has completed undeployment and so from a
Context lifecycle point of view everything should now be dead.

But some active thread is still doing work and may run for sometime before
ultimatly calling on the services of WebappClassLoader to load a new class, but
all the supporting infrastructure to do that job has now been cut away and
disposed of by TC (because the context is dead).

All of the code and execution threads that make up a Context instance MUST
adhere to the lifecycle of that Context as defined by the respective 
specification, this includes background threads.


Here are some of my best practices on the use of background threads within
webapp context's:

* You must be able to signal a thread cancellation to be able to control the
shutdown part of the background thread lifecycle. 

* You must put code into your ServletContextListener.destroyContext() that
broadcasts a controlled Thread cancellation to all background threads.

* Your must then reap (wait for the termination of) every single background
thread before allowing the #destroyContext() to return control back to the
container.

* It is advisable that all background threads must be able to detect their
cancellation signal, cleanup and terminate within a short period of time.  Maybe
realistic goals are in the order of 5 seconds to detect, 2 seconds to terminate.
 This means that your threads should not use design patterns that would put them
in a blocking state that would exceed these goals.



To help understand your problem better can you provide some details:

* The execution path to the ThreadDeath Exception.

* Is your JDBC driver in the $CATALINA_HOME/commons/ hiearachy ?

* Does your JDBC driver use or create any Singleton strong references ?

* Do you ever get this problem on first use after a container restart ?

* Are you only seeing this problem after at least on webapp/context reload has
taken place on the affected webapp ?

* Is a PhantomReference another name for a Weak Reference ?  What is that for
the technicaly naive.

* How do you create and setup your JDBC connection ?  Does the container manager
the connection instances or do you create them manually within the web-app ?


I can see how any code path could allow the execution of classes loaded from
WebappClassLoader before the class loader instance itself has been setup.  But I
can imagine a situation where you access an object that was created by a
previous instance that is now a zombie.  If this is what I think you are seeing
then you should be unable to re-create the problem of you restart the entire
container and deploy the web-app for the first time.

Can you use a container managed JDBC connection (if not already doing so).

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