On 11 Dec 2010, at 21:39, Srikanth Konjarla <srikanth.konja...@gmail.com> wrote:
> > On Dec 11, 2010, at 1:04 PM, "Pid *" <p...@pidster.com> wrote: > >> On 11 Dec 2010, at 20:02, Srikanth Konjarla <srikanth.konja...@gmail.com> >> wrote: >> >>> 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. >> >> The above means that something is storing the WebappClassLoader in a >> ThreadLocal. Is your app doing this? >> >> The two below I know about and I believe are defects in Axis 1.4. > The only component that uses threadlocals in my app is Axis and I believe it > is not cleaning up after completely. I agree. > Originally, I have started on tracking down Axis threads that are > responsible. In this case, Axis is performing webservice client operations. Then you are also seeing an additional problem - namely that the classloader itself is being stored in a threadlocal. I haven't seen Axis do that so far. You may need to use a newer version of Axis - I don't think v1 is expected to do any more releases. p > Srikanth >> >> >> p >> >>> 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 >>> >> >> --------------------------------------------------------------------- >> 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
