[
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