On 17/12/2010 15:38, Srikanth Konjarla wrote:
>
>
> On 12/17/10 3:01 AM, Pid wrote:
>> On 15/12/2010 15:37, Srikanth Konjarla wrote:
>>>
>>>
>>> On 12/15/10 7:13 AM, Pid wrote:
On 15/12/2010 02:40, Srikanth Konjarla wrote:
> I could catch Axis threadlocals from the app to clean up. Howev
On 12/17/10 3:01 AM, Pid wrote:
> On 15/12/2010 15:37, Srikanth Konjarla wrote:
>>
>>
>> On 12/15/10 7:13 AM, Pid wrote:
>>> On 15/12/2010 02:40, Srikanth Konjarla wrote:
I could catch Axis threadlocals from the app to clean up. However, I
have a question wrt following tomcat's log at t
On 15/12/2010 15:37, Srikanth Konjarla wrote:
>
>
> On 12/15/10 7:13 AM, Pid wrote:
>> On 15/12/2010 02:40, Srikanth Konjarla wrote:
>>> I could catch Axis threadlocals from the app to clean up. However, I
>>> have a question wrt following tomcat's log at the time of undeploy of
>>> app. The mess
On 12/15/10 7:13 AM, Pid wrote:
> On 15/12/2010 02:40, Srikanth Konjarla wrote:
>> I could catch Axis threadlocals from the app to clean up. However, I
>> have a question wrt following tomcat's log at the time of undeploy of
>> app. The message suggests that it is removing the same threadlocal
>>
On 15/12/2010 02:40, Srikanth Konjarla wrote:
> I could catch Axis threadlocals from the app to clean up. However, I
> have a question wrt following tomcat's log at the time of undeploy of
> app. The message suggests that it is removing the same threadlocal
> twice. Is it because it was not removed
;
>>>>>>>>>> https://jira.springframework.org/browse/SWS-533
>>>>>>>>>
>>>>>>>>> Similarities in which sense?
>>>>>>>>> The issue was closed as invalid.
>>>>>>>>
On 13/12/2010 12:23, Pid wrote:
> On 12/12/2010 18:18, Srikanth Konjarla wrote:
>>
>>
>> On 12/12/10 8:28 AM, Pid * wrote:
>>> On 11 Dec 2010, at 21:39, Srikanth Konjarla
>>> wrote:
>>>
On Dec 11, 2010, at 1:04 PM, "Pid *" wrote:
> On 11 Dec 2010, at 20:02, Srikanth Konjarla
;
>>>>>> 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
t;>>> your problem.
>>>>>
>>>>> If the thread is reused by tomcat, what happened to the references from
>>>>> previous cycle.
>>>>>
>>>>> Which references? The ThreadLocals?
>>>>>
>>>>> If a Thr
;>> 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 we
> 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
>>>>
Some short answers :
- (for the moment) threads are always reused, even after an application is
stopped.
- tomcat 6.0.26 tries to clean the threadlocals which may provoke a leak, but
1) it was unsafe and has been disabled by default from 6.0.27 (see
https://issues.apache.org/bugzilla/show_bug.c
27;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
>>> wonderi
>>> 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
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.
ale, 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 remo
, because I
believe it causes a leak.
Please post the warnings from your logs so I can see of it's the same problem.
p
>
> Srikanth
>
> On 12/10/10 3:41 PM, Caldarale, Charles R wrote:
>>> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com]
>>> Subject:
BTW, I see some similarities with the following.
https://jira.springframework.org/browse/SWS-533
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 ob
>
>>
>> Srikanth
>>
>> On 12/10/10 2:36 PM, Caldarale, Charles R wrote:
>>>> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com]
>>>> Subject: 6.0.26 java.lang.Thread.State: WAITING (on object monitor)
>>>
>>>> Essentially, the
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,
of Axis you're using here.
p
>
> Srikanth
>
> On 12/10/10 2:36 PM, Caldarale, Charles R wrote:
>>> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com]
>>> Subject: 6.0.26 java.lang.Thread.State: WAITING (on object monitor)
>>
>>> Essential
> 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 still being in "WAIT" mode and been cleaned up.
Srikanth
On 12/10/10 2:36 PM, Caldarale, Charles R wrote:
>> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com]
>> Subject: 6.0.26 java.lang.Thread.State: WAITING (on object monitor)
>
>> Essential
> From: Srikanth Konjarla [mailto:srikanth.konja...@gmail.com]
> Subject: 6.0.26 java.lang.Thread.State: WAITING (on object monitor)
> Essentially, the thread has threadLocals object that has
> few references.
And who put the ThreadLocal there? (Hint: it wasn't Tomcat; y
All,
I have a webservice client in the webapp. When the webapp is undeployed
the classloader has not been GC'ed. Upon investigation it is found that
a thread is in WAIT state which has references to the webapp class
loader. I see the following from heap dump.
http-8080-2
at java.lang.Object.wai
25 matches
Mail list logo
