Question

I’ve begun playing with MBeans for exposing some information about an app. Pretty much the totality of HOWTOs / Tutorials / Blog posts / Samples online teach you how to implement an MBean and register it with an MBean Server, but never mention (or only cursorily) unregistering the MBean from the server.

I’m concerned about an MBean that needs to have a reference to a fairly heavyweight object in order to provide status information about that object.

Does the Platform MBean Server maintain a weak reference to the MBean, or some other such trick, to ensure that it eventually gets GC’ed if your application no longer holds any references to it? Is unregistering generally unnecessary, thereby explaining why no one is talking about it in JMX tutorials?

Answer 1

You can not ‘weakly’ register an MBean with a server (yet), thereby expecting it to be GCed when no other references to it exist.

This being said, you should definitely read some posts by Eamonn McManus on the subject.

https://web.archive.org/web/20120207140653/http://weblogs.java.net/blog/emcmanus/archive/2005/07/cleaning_up_an_1.html

It’s been suggested that the JMX API could have some explicit support for ‘Weak MBeans’ like this. I’m not sure there’s enough use for them to justify including them in the API, and I’m also not sure what a general-purpose API for Weak MBeans would look like. But the above shows how you can create your own Weak MBeans if need be.

https://web.archive.org/web/20090114131740/http://weblogs.java.net/blog/emcmanus/archive/2005/07/javaone_feedbac.html

‘Weak’ MBeans. An MBean frequently manages another Java object that is the ‘resource’ to be monitored or controlled. But what if the only reference to that resource is from the MBean? Could we somehow arrange for the MBean to disappear if the resource is no longer referenced by anyone else?

Turning on and off expensive MBeans. Some MBeans may export information that is continuously sampled and that is expensive to gather. You don’t necessarily want those MBeans to be running all the time. Ad hoc solutions are easy, for instance the setThreadContentionMonitoringEnabled method in java.lang.management.ThreadMXBean. But perhaps there could be a more general convention, such as a setDetailLevel(int) method.