JDK-5108739 : Support virtual MBeans
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P5
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2004-09-29
  • Updated: 2008-09-04
  • Resolved: 2008-09-04
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.
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Some applications have very large numbers of managed objects.  As the JMX API stands today, these applications must therefore have very large numbers of MBeans, each of which corresponds to a Java object.  So the memory footprint can be significant.

Likewise, in some applications managed objects come and go very rapidly.  If they are to be reflected by MBeans, the MBeans must constantly be created and destroyed to reflect the current state.  This happens even during quiet periods when the MBeans are not being referenced.

A way to improve these two situations would be to support "virtual MBeans".  A virtual MBean does not correspond to a permanent Java object, but is called into existence when it is referenced and can disappear afterwards.

One way to allow virtual MBeans is via "MBean Server interceptors".  The idea here is that one or more objects implementing the MBeanServer interface can be inserted between the MBeanServer object that user code sees (as returned by ManagementFactory.newMBeanServer for instance) and the "real" MBeanServer that handles the Java objects corresponding to MBeans:

+--------+           +-------------------------+           +--------+
|User MBS|    -->    |Virtual files interceptor|    -->    |Real MBS|
+--------+           +-------------------------+           +--------+

In this picture, the "virtual files interceptor" (VFI) is an object that implements the MBeanServer interface and that handles virtual MBeans for a filesystem.  Every file in the filesystem is reflected by an MBean.  Suppose a method in the MBeanServer interface is called on the VFI.  Let's say the method is getAttribute(ObjectName name, String attr).  The VFI examines the ObjectName.  If the ObjectName specifies the "files" domain then the VFI will handle the method itself and return the value for the named attribute applied to the file whose name is in the rest of the ObjectName.  If, on the other hand, the ObjectName specifies a different domain then the VFI will simply call getAttribute on the next MBeanServer object in the chain.  In the picture, this is the "real MBean Server", so the behaviour will be the same as if there were no VFI.

In code, we could have something like this:

public VirtualFilesInterceptor implements MBeanServer {
    public VirtualFilesInterceptor(MBeanServer next) {
        this.next = next;

    public Object getAttribute(ObjectName name, String attr) throws ... {
        if (name.getDomain().equals("files"))
            return getFileAttribute(name.getKeyProperty("filename"), attr);
            return next.getAttribute(name, attr);

Today, it is possible to achieve something like this by exploiting the ability to specify an MBeanServerBuilder, but it is not convenient.  It would be somewhat more convenient if there were static methods to set and get the current MBeanServerBuilder, but even then this would imply the same interceptors for every MBean Server created in a given JVM.

Other API possibilities include making a new MBeanServer2 interface that extends the existing MBeanServer and adding new methods such as setInterceptor and getInterceptor to it (adding methods to the existing MBeanServer interface would break existing source code that implements this interface); or specifying that every MBeanServer must contain a predefined MBean with a name like JMImplementation:type=InterceptorManager whose operations allow the interceptors to be configured.

Note that the idea of MBean Server Interceptors is not the same as the MBean interceptors used by certain app servers.  In that case, there can be a chain of objects between the MBeanServer object that a user sees and any individual MBean object.  The chain for one MBean object can be different from that for another MBean object.  But in every case the chain terminates with a real Java object, so this pattern does not address the problems of large numbers of MBeans or very volatile MBeans.

EVALUATION While the interceptor framework is powerful, it is also relatively hard to use. A lot of the time it would be sufficient to be able to say "requests for an MBean whose name matches this pattern should be directed to this handler". Predefined classes could also be provided for certain types of handler, e.g. one that allows you to use Standard MBean design patterns to code attributes and operations. This might look something like this: addVirtualMBeanHandler(objectNamePattern, new StandardVirtualMBeanHandler(Foo.class)); When you do mbeanServer.getAttribute(someName, "Bar"), and someName matches objectNamePattern, then the handler will instantiate a Foo, tell it that its name is someName (via a constructor parameter or MBeanServerRegistration.preRegister or a new interface), and call getBar() on it. The new object could be kept around in a cache in case there are other requests on the same MBean in the near future. Virtual MBeans are conceptually stateless Java objects so there should be no need to tell the object when it is no longer being used.


EVALUATION Seems like a good idea. Sun's Java Dynamic Management Kit already supports interceptors. Might be worth providing some predefined interceptors, though, for example a predefined way to handle all MBeans with a given ObjectName domain. Not sure that this is enough of a problem to justify tackling it in the Mustang timeframe. ###@###.### 2004-09-29