[jboss-user] [Installation, Configuration & DEPLOYMENT] - ClassLoader leak through TimedCachePolicy.resolutionTimer

[huuskart]

As far as I can see, a ClassLoader leak can occur through org.jboss.util.TimedCachePolicy.resolutionTimer, preventing ClassLoader and classes from unloading when an EAR is undeployed.

I have debugged undeploy problem in my EAR with jmap -dump and jhat, and one of the reasons preventing ClassLoader from unloading is this path I see in jhat:

Static reference from org.jboss.util.TimedCachePolicy.resolutionTimer (from class org.jboss.util.TimedCachePolicy) :
--> java.util.Timer at 0x2aa6b49830 (40 bytes) (field thread:)
--> java.util.TimerThread at 0x2aa6ac8b58 (173 bytes) (field contextClassLoader:)
--> org.jboss.web.tomcat.service.WebAppClassLoader at 0x2aa69dc338 (296 bytes) (field parent:)
--> java.net.FactoryURLClassLoader at 0x2aa69b5498 (123 bytes) (field parent:)
--> org.jboss.mx.loading.UnifiedClassLoader3 at 0x2aa5ef3ec0 (203 bytes) 

The Timer object in the trace has only one TimedCachePolicy job in its queue, and that object is referenced from

org.jboss.security.plugins.JaasSecurityManager at 0x2aa6cd0fb0 (103 bytes)  : field domainCache
org.jboss.security.plugins.SecurityDomainContext at 0x2aa6cd0f90 (32 bytes) : field authenticationCache

So I'm guessing that this happens: when I first access my web application requiring authentication, JBoss creates the Timer needed to clean authCache and domainCache. This Timer is created from the context of my web app -> the TimerThread java.util.Timer creates inherits the current context ClassLoader, that is my ClassLoader. Boom.

As a side issue, a peculiar thing is that I have disabled authenticationCache with

0

for JaasSecurityManagerService. Even more peculiar, the authenticationCache actually does contain the principal and credentials I used to log in to the web app. That is, authCache can't be disabled the way it is advertised.

A possible work around is to access something else, like jmx-console first, causing the Timer to be created in that context. I'll try that shortly.


There is also another ClassLoader leak that comes from Tomcat. See https://issues.apache.org/bugzilla/show_bug.cgi?id=44389

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4134171#4134171

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4134171