[jboss-jira] [JBoss JIRA] Closed: (JBAS-5270) ClassLoader not unloaded on undeploy

[Adrian Brock (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-5270?page=all ]

Adrian Brock closed JBAS-5270.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Scott M Stark)

Your test application does NOT show a classloader leak.

I tried deploying/undeploying it and running jhat and yes it does show your classes
still around. But this is not a memory leak.

The reason they are still there is because Sun's java.lang.reflect.Proxy
contains a WeakHashMap which holds a reference to the $Proxy classes in its
ReferenceQueue in its "loaderToCache" instance field.
i.e. it is ready to be garbage collected

They are still in the ReferenceQueue because a WeakHashMap
only clears up things lazily, i.e. next time you access it.

When I deploy another EJB, it will create new proxies which will access the WeakHashMap
and clears the old reference.

e.g.
1) I deploy a completely different EJB, your classes disappear from the dump
2) If I redeploy your EJB, the old classes are no longer visible and neither is the old classloader

This cannot be the cause of a permenant generation exhaustion unless your permenant
generations is too small to survive a single redeploy of your application.
i.e. it is nearly full before the redeploy

Most likely your leak (I wouldn't describe it as orphaned since somebody is still 
referencing it), if there is one, is caused by static singletons in your code or
thirdparty code you use. e.g. certain apache commons projects are notorious for causing
this problem, or you have some other application deployed still referencing classes
from the undeployed application

But please, do not discuss this further here, use the forums to ask for help unless you can
show an org.jboss.* class as a strong reference to an undeployed classloader/class.

Your  example just shows a JDK class holding a WeakReference that is ready to be reaped.

> ClassLoader not unloaded on undeploy
> ------------------------------------
>
>                 Key: JBAS-5270
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5270
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.2.1.GA
>         Environment: JDK 1.6.0_04 amd64
>            Reporter: Arto Huusko
>         Attachments: simpleejb.ear
>
>
> When an EAR is undeployed, its ClassLoader and classes loaded by it are not unloaded, which leads to out of memory error in permanent generation on redeploy.
> It appears that the ClassLoader becomes an orphaned ClassLoader (see http://blogs.sun.com/edwardchou/entry/find_orphaned_classloaders), and apparently JVM is unable to GC such ClassLoader instances (if it were, I don't understand the point of the blog about orphaned loaders).
> My simple test ear contains one stateless session EJB (2.1), with a simple "echo" method (takes string, returns string). Jhat shows that the only reference to the ClassLoader instance comes from static field m3 in class $ProxyNN, where $ProxyNN is loaded by the same ClassLoader (in case it makes any difference, m3 points to the create method of the local home interface of the session).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira