The RMI Connector forwards notifications to remote listeners by adding its own local listener to every MBean that is a NotificationBroadcaster, and dispatching every notification to the appropriate remote listeners. As pointed out by ###@###.###, the logic to do this is susceptible to race conditions which can result in two listeners being added to the same MBean. If this happens, every notification emitted by that MBean will be sent twice to all interested remote listeners.

Races can arise when an MBean is unregistered and then immediately registered again. This can happen for example when the MBean needs to be replaced by a more recent version.

The first race arises only if two threads try to register the same MBean X at the same time. We can see this:

t1:
  register MBean X
  send MBeanServerNotification.registered
t2:
  unregister MBean X
  send MBeanServerNotification.unregistered (currently ignored)
  register MBean X
  send MBeanServerNotification.registered
  connector server does addNotificationListener(X)
t1:
  connector server does addNotificationListener(X)

Notice that the two threads are racing each other, which means that the program containing them is probably incorrect. In scenarios other than the one shown here, one of the threads would have got an InstanceAlreadyExistsException.

The second race condition, which is new with the fix to 6239400, occurs when the unregister/register sequence happens during the initial scan of NotificationBroadcaster MBeans that the connector server does when it starts:

t1:
  query all NotificationBroadcaster MBeans, including X
t2:
  unregister MBean X
  register MBean X
  send MBeanServerNotification.registered
  connector server does addNotificationListener(X)
t1:
  connector server does addNotificationListener(X)

The two race conditions are very similar. In both cases, a thread adds a listener to an MBean that was really intended for an earlier incarnation of that MBean.
###@###.### 2005-03-17 16:45:20 GMT