Pid, Thanks for your patience. Here is the output from catalina.out file while the webapp is being undeployed. As you can see there are few threadLocals that are cleaned up.
---------------------------------------------------------------------- Dec 10, 2010 8:46:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@7ee75db3]) and a value of type [org.apache.catalina.loader.WebappClassLoader] (value [WebappClassLoader delegate: false repositories: /WEB-INF/classes/ ----------> Parent Classloader: org.apache.catalina.loader.standardclassloa...@1eb3319f ]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Dec 10, 2010 8:46:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.threadlo...@7ee75db3]) and a value of type [org.apache.catalina.loader.WebappClassLoader] (value [WebappClassLoader delegate: false repositories: /WEB-INF/classes/ ----------> Parent Classloader: org.apache.catalina.loader.standardclassloa...@1eb3319f ]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Dec 10, 2010 8:46:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [org.apache.xml.security.utils.UnsyncByteArrayOutputStream$1] (value [org.apache.xml.security.utils.unsyncbytearrayoutputstrea...@775d1479]) and a value of type [byte[]] (value [...@5faeed4]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Dec 10, 2010 8:46:56 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [org.apache.axis.utils.XMLUtils.ThreadLocalDocumentBuilder] (value [org.apache.axis.utils.xmlutils$threadlocaldocumentbuil...@3a0ee334]) and a value of type [org.apache.xerces.jaxp.DocumentBuilderImpl] (value [org.apache.xerces.jaxp.documentbuilderi...@61583db6]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. ------------------------------------------------------------------------ Srikanth On 12/11/10 2:26 AM, Pid wrote: > On 12/11/10 9:25 AM, Srikanth Konjarla wrote: >> >> >> On Dec 11, 2010, at 1:18 AM, "Pid *" <p...@pidster.com> wrote: >> >>> On 11 Dec 2010, at 01:07, Srikanth Konjarla <srikanth.konja...@gmail.com> >>> wrote: >>> >>>> BTW, I see some similarities with the following. >>>> >>>> https://jira.springframework.org/browse/SWS-533 >>> >>> Similarities in which sense? >>> The issue was closed as invalid. >> The similarity is that the thread is retained. > > This is not a problem. The threads exist in a pool and are reused. > > Chuck explained why the WAIT status isn't a problem. > > However, other than the case is invalid it does not provide detail why > it is invalid and why the thread is in WAIT state. > > Yes, it does. It also refers to JAXB, not Axis. So it's unrelated to > your problem. > > If the thread is reused by tomcat, what happened to the references from > previous cycle. > > Which references? The ThreadLocals? > > If a ThreadLocal is created by an application, but not cleaned up, the > thread still contains the reference in the internal map of ThreadLocals. > If the reference is to a class from a webapp which is subsequently > unloaded, then the classloader will not be garbage collected. > > > I would be interested in learning. > > PLEASE post the leak warnings from your logs. > > > p > > > >>> You're using Axis 1.4 which I've been looking at recently, because I >>> believe it causes a leak. >> I believe the same but wanted to make sure that leaking threads are captured >> and cleaned during the undeploy process. Additionally, I was wondering how I >> can detect and locate runaway Axis threads with thread locals. >>> >>> Please post the warnings from your logs so I can see of it's the same >>> problem. >> Will do. >> >> Srikanth >>> >>> >>> p >>> >>>> >>>> Srikanth >>>> >>>> On 12/10/10 3:41 PM, Caldarale, Charles R wrote: >>>>>> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com] >>>>>> Subject: Re: 6.0.26 java.lang.Thread.State: WAITING (on object monitor) >>>>> >>>>>> as part of the thread local cleanup process at the time of undeploy, >>>>>> tomcat removes few threadLocals but misses the threadLocals for the >>>>>> thread in question. I am wondering about the tomcat thread still being >>>>>> in "WAIT" mode and been cleaned up. >>>>> >>>>> The WAIT mode is normal - the thread is sitting in the pool, waiting for >>>>> a request to show up. I believe the ThreadLocal objects are discarded by >>>>> letting such infected threads exit and creating new ones. That's an area >>>>> still undergoing refinement, so you might want to try moving up to 6.0.29 >>>>> and see if it makes any difference. Or try sending in enough concurrent >>>>> requests to get all the threads busy and see if the references disappear >>>>> after that. >>>>> >>>>> - Chuck >>>>> >>>>> >>>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >>>>> MATERIAL and is thus for use only by the intended recipient. If you >>>>> received this in error, please contact the sender and delete the e-mail >>>>> and its attachments from all computers. >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org