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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
