3 Replies Latest reply on Aug 20, 2007 12:03 PM by starksm64

    JBAS-4593 -- Leaking classloader via JMX Notifications

    brian.stansberry

      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 http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMBeansInJConsole.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.