JDK-6356458 : Missed popDefaultClassLoader() in RMIConnector.addListenerWithSubject()
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0u4
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-11-29
  • Updated: 2010-07-29
  • Resolved: 2006-01-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u7Fixed 6 b67Fixed
Description
RMIConnector.addListenerWithSubject() method has call to pushDefaultClassLoader() but no corresponding call to popDefaultClassLoader().  This would lead to changing current thread context class loader when using the method unless the context class loader is the same as the RMIConnector default class loader.
Comments
WORK AROUND Instead of mbeanServerConnection.addNotificationListener, call this method: public static void addNotificationListener(MBeanServerConnection mbsc, ObjectName name, NotificationListener listener, NotificationFilter filter, Object handback) throws InstanceNotFoundException, IOException { ClassLoader oldcl = Thread.getContextClassLoader(); try { mbsc.addNotificationListener(name, listener, filter, handback); } finally { Thread.setContextClassLoader(oldcl); } }
01-12-2005
EVALUATION In fact the method RMIConnector.addListenerWithSubject() does not need to call pushDefaultClassLoader, because this method does not use directly the underlying connection (RMI). So the fix is to remove the call of pushDefaultClassLoader.
01-12-2005
EVALUATION In fact there is another case to see the bug: calling "addNotificationListener" from a JMX client will result to lose a calling user context classloader, if it is different to the clientn default classloader. In this case the bug has to be fixed also in the Tiger.
30-11-2005
WORK AROUND Have a classloader explicitly restored after .addNotificationListener function call *** (#1 of 1): [ UNSAVED ] ###@###.###
30-11-2005
EVALUATION The condition to reproduce the problem is: 1) There are remote listeners; 2) the thread used to fetch notifications is blocked at the client side when dispatching notifications; 3) the server connection monitor is enabled and gets timeout because the thread of fetching notification is blocked longer than the monitor timeout, there is no client request to the server during the monitor timeout, and the checking period of the client heartbeat is longer than the monitor's timeout or the heartbeat is disabled; 4) after the server monitor closes the connection, the reconnection is started by a client request but not by the thread of fetching notification or the thread of client heartbeat; 5) the classloader used for the client request is diffierent to the default class loader. So it is really rare to get this problem. We will fix it in mustang without regression test (too hard), and we will not fix it in the tiger and in the unbandled remote jmx except getting a user request.
30-11-2005