Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of rainer.jung@kippdata.de
 designates 195.227.30.149 as permitted sender)
Message-ID: <4BE39ED8.6050001@kippdata.de>
Date: Fri, 07 May 2010 07:02:16 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: clearReferencesThreads, Poller SunPKCS11-Solaris and strange
 context class loader
References: <4BE30FAA.1040607@kippdata.de>
 <F9623C40-9E74-4063-9292-FD17E2E020A9@m4x.org>
In-Reply-To: <F9623C40-9E74-4063-9292-FD17E2E020A9@m4x.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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