[jboss-jira] [JBoss JIRA] Resolved: (JBAS-4593) Leak in org/jboss/mx/loading/UnifiedClassLoader3

[Scott M Stark (JIRA)]

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

Scott M Stark resolved JBAS-4593.
---------------------------------

    Fix Version/s:  JBossAS-5.0.0.Beta3
                   JBossAS-4.2.2.GA
       Resolution: Done

Added a org.jboss.mx.loading.UnifiedLoaderRepository.notifyMode system property that controls how whether a jmx notification is sent, if done, whether the class loader is wrapped in a WeakReference. It should be set to one of 0, 1 or 2:
   // Send notification with the ClassLoader as the user data
   private static int LEGACY_MODE = 0;
   // Send notification with the ClassLoader as the user data wrapped in a WeakReference
   private static int WEAK_REFERENCE_MODE = 1;
   // Don't send any notifications
   private static int NO_NOTIFICATION_MODE = 2;

The default is the LEGACY_MODE.


> Leak in org/jboss/mx/loading/UnifiedClassLoader3
> ------------------------------------------------
>
>                 Key: JBAS-4593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4593
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Mike Millson
>         Assigned To: Scott M Stark
>             Fix For:  JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
>
>
> [description pasted from support case]
> After many redeploys of applications, we have JVMs failing with "OutOfMemory perm gen" errors. We have installed the JBoss profiler, and taken heap dumps when the JVM is close to failing (after deploying and undeploying an application ~30 times). By searching for classloaders that have "com.XXX" classes loaded, and then searching for paths to heap roots from those classloaders, we have identified what we believe to be a leak associated with instances of org/jboss/mx/loading/UnifiedClassLoader3. Specifically, we see strong paths to heap roots like the following:
> found a path to the target: 26093 (depth: 5)
> 0 0 Heap root
> 26636 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer;
> 124809 0 Instance: Lcom/sun/jmx/remote/internal/ArrayQueue;
> 160611 0 Instance: [Ljava/lang/Object;
> 161523 0 Instance: Lcom/sun/jmx/remote/internal/ArrayNotificationBuffer$NamedNotification;
> 217357 0 Instance: Ljavax/management/Notification;
> 26093 26106 Instance: Lorg/jboss/mx/loading/UnifiedClassLoader3;
> So, even though our application is undeployed, strong paths from their classloaders to heap roots exist.
> Specifically, it appears that this might be related to registering the classloader to receive JMX notifications and not unregistering it on an application undeploy. Please advise on what you think is the best strategy for resolving this problem.

-- 
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