The way an RMI Connector Server handles notifications is as follows. It adds a listener, call it the connectorListener, to every MBean that is a NotificationBroadcaster. Every time a remote client adds a listener to an MBean, the Connector Server records that in a list, but does not actually do anything to the MBean itself. When an MBean emits a Notification, the connectorListener receives it, and consults its list of remote listeners to see which ones are concerned. These remote listeners receive the notification.

The problem is that the search for interested listeners runs through the complete list of all listeners. If a remote client adds one listener to each of 1000 MBeans, then any time an MBean emits a Notification, all 1000 listeners will be consulted to see if they are concerned.

This is obviously inefficient. The connectorListener knows which MBean a Notification is coming from. Therefore it should only check remote listeners that are registered on that MBean.

This problem is not just theoretical. In a "cascading" solution, a set of MBeans from one or more "subagents" are reflected by proxies in a "master agent". If the master agent has a Connector Server, this Connector Server will add a listener to each of the proxies, which will mean adding a remote listener to each of the proxied MBeans in the subagents. If the master agent has proxies for 1000 MBeans in a given subagent, it will add 1000 remote listeners in that agent, and every Notification emitted in that subagent will have to go through the list of 1000 listeners.