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

[Anil Saldhana (JIRA)]

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

Anil Saldhana updated JBAS-4593:
--------------------------------

    Description: 
[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.



  was:
[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.amfam" 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.




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