[jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - JBAS-4593 -- Leaking classloader via JMX Notifications

bstansberry@jboss.com do-not-reply at jboss.com
Wed Aug 15 16:24:11 EDT 2007


Mike Millson asked me to have a look at http://jira.jboss.com/jira/browse/JBAS-4593; reporting here what I've found:

The heap info posted on the case shows a path leading from a UnifiedClassLoader3 through a JMX Notification and on to a heap root.
When an instance of UnifiedClassLoader3 is created, it causes the generation of a JMX Notification with the classloader as the Notification userData.  The path to heap root shows one of those notification being held in a buffer in Sun's internal JMX implementation classes.  User is using the platform mbeanserver as discussed on [url]http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMBeansInJConsole
[/url].the ke

>From poking around in the JDK code, I believe the buffer that's holding the Notification is doing so to deliver the notifications to a remote JMX client.  Looks like the Sun JMX code creates a buffer the first time a remote JMX connection is established. Buffer holds a configurable number of Notifications, default is 1000.  Size of buffer can be controlled by system property "jmx.remote.x.notification.buffer.size".

At this point I'm not sure what to do about the issue.  Some options:

1) Get rid of the JMX notifications.
2) Wrap the classloader in a WeakReference before adding to the notification.

3) Workaround: help user figure out what's making the remote JMX connection and how to get it to drain the buffer.
4) Workaround: help user configure a smaller buffer size so the leak is cleared more quickly as the old notification is purged from the buffer.

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

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



More information about the jboss-dev-forums mailing list