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