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 *" <[email protected]> wrote:
>>
>>> On 11 Dec 2010, at 01:07, Srikanth Konjarla <[email protected]>
>>> 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:[email protected]]
>>>>>> 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: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
