This CR groups several existing RFEs intended to improve the scalability of JMX technology.  Here scalability means performance when there are large numbers of objects and/or large numbers of agents (remote monitored JVMs).

The relevant subfeatures are as follows:

5108739 Virtual MBeans

This will allow there to be a very large number of MBeans without having to have a Java object for every one.  It will also cover the case where enumerating or keeping track of the MBeans is costly; currently MBeans are Java objects and if the Java object for a particular MBean has not been created then the MBean cannot be accessed.  (Example: MBeans representing system processes.  Enumerating all system processes and tracking their creation and destruction is costly.  If the user knows the id of a process of interest, they can just name the corresponding MBean without having to see it in a list.)

6323764 Client Sessions

It is often the case that a remote JMX client wants to perform a number of operations, with some state required across these operations. This feature would introduce support for sessions. It would be exploited by other proposed features (at least the Event Service). It would also be useful for things like performance-measurement jobs and long-running asynchronous operations.

5108776 Event Service

The existing treatment of remote notifications suffers from several problems. One is that notifications can be lost because of heavy traffic or network failure. A second is that a client must maintain an open network connection to every server it wants to get notifications from, which is bad when there are many servers. A third is that a client must explicitly register with every individual MBean it wants to get notifications from.

The proposed solution is to define an event service, which is an MBean that clients can interact with to subscribe to notifications. As at present, clients could provide filters to specify which notifications are of interest. The event service would be pluggable into event delivery back ends such as JMS. It would use client sessions to ensure that subscriptions from dead clients expire.

5072476 Cascading (Federation)

Several implementations based on the JMX API support cascading or federation. The idea is that one or more "subagents" can have some or all of their MBeans proxies into a "master agent", where "agent" means MBean Server. This allows a client to connect to just the master agent, rather than to each subagent, which simplifies configuration, security, and usage, by providing a single entry point.  It also allows reducing the number of connections from any client (including agent connections to subagents); for example 1000 agents can be structured in a tree where the top-level agent connects to 10 others, each of which connects to 10 others, and so on.  This avoids running into operating system limits on the number of connections or file descriptors.

A classic use case for cascading is in clustered App Servers.  A management client for an app server wants to connect to just one entry point, but then be able to manage everything in the cluster.  Cascading provides an immediate solution, and most if not all existing clustered app servers have some form of proprietary cascading.

It is expected that cascading will be built using Virtual MBeans.