Hi Mark, I have a multiwar app. I made the changes to one war in myway/META-INF/context.xml
<Context path="/mywar" clearReferencesStopThreads="true" clearReferencesThreadLocals="true"> </Context> The issue is: 1.When I use tomcat manager to deploy the war, it doesn't respect the path attribute of the war. i.e my war is by the name mywar-R10-SNAPSHOT.war, so the context is set as mywar-R10-SNAPSHOT rather than just mywar. 2. How can I confirm if clearReferencesStopThread and clearReferencesThreadLocals attributes are being respected or not?? Thanks -- Neeraj On Tue, Mar 22, 2011 at 8:38 PM, Mark Thomas <ma...@apache.org> wrote: > On 22/03/2011 14:42, neeraj kumar wrote: > > Hi , > > > > I am using Tomcat 6.0.18 , JVM Version 1.6.0_24 ,OS SunOS 5.10, OSArch > > :AMD64 > > > > Recently I observed in few apps deployed on tomcat, that when I undeploy > the > > apps by simply deleting the .war file and the directory for the app, a > few > > threads are not cleaned up. > > > > I would be happy if someone shed some light on the following: > > > > 1, Is there a way of a full clean undeployment of a webapp ? > > No. There is no safe mechanism to stop an application created thread. > There are some very dirty hacks you can use but they are very unstable. > See clearReferencesStopThreads in > http://tomcat.apache.org/tomcat-7.0-doc/config/context.html > > In testing I managed to crash the JVM about 50% of the time with that > option enabled. > > By far the best way to fix this issue is for the application to stop any > threads it starts using a ServletContextListener. I view failure to do > so as a serious application bug since is triggers a heap of issues > including PermGen memory leaks. > > > 2. Does tomcat manager help the developer/administrator in a full cleanup > of > > an app during undeployment , or even the manager simply deletes the war > and > > lets the tomcat container take care of undeploying?? > > The Manager adds a little logic to prevent some race conditions that may > occur if you just delete the file. It is marginally safer but there is > no extra clean-up performed. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
