tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: clearReferencesThreads, Poller SunPKCS11-Solaris and strange context class loader
Date Fri, 07 May 2010 05:02:16 GMT
On 06.05.2010 23:24, Sylvain Laurent wrote:
> When you analyzed the heap dump, what path to GC roots was retaining the classloader
in memory ?

I did the heap dump before the context restart.

Note: I don't want to debug a memory leak. I'm wondering why the PCKS 
Token Poller thread was captured by the leak prevention. Since we know 
the code, it was because its context class loader was equal to the 
WebappClassLoader of /manager. That's what I don't understand. See my 
original post.

Regards,

Rainer

> On 6 mai 2010, at 20:51, Rainer Jung wrote:
>
>> While doing some testing with 6.0.26 I noticed, that when shutting it down it logs
an error about thread "Poller SunPKCS11-Solaris" not being stopped. When I add the more explicit
logging from tc6 trunk, it says the thread was started by /manager.
>>
>> The thread sits in
>>
>> java.lang.Thread.State: TIMED_WAITING (sleeping)
>> at java.lang.Thread.sleep(Native Method)
>> at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:681)
>> at java.lang.Thread.run(Thread.java:619)
>>
>> and is started for some version of the JDK (noted on Solaris for e.g. 1.5.0_22 and
1.6.0_3, not for 1.6.0_17) even without having anything related to keystores, https or similar
configured in Tomcat (default config). The only non-default is using Log4J instead of Juli.
>>
>> What is strange, is that the check whether the context class loader of the thread
is equal to the WebappClassLoader of the context to unload passes. I added an additional output
by explicitely printing the contextName of the two loaders and in fact both print "/manager".
>>
>> When deploying two instances of the manager and reloading the original instance with
the additional one, I get the same warning.
>>
>> In a heap dump, it seems the context class loader of the thread is the system class
loader and not of type WebappClassLoader. Any idea, why the context class loader test fails?
Is there any reason why the context class loader of the thread might change when doing the
manager reload or shutdown?
>>
>> Regards,
>>
>> Rainer
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message