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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
