JavaOne feedback about JMX technology

JavaOne is always a huge buzz, and this year was no exception. Of
course the technical sessions are very worthwhile, so it's great news
that slides and audio for all of them will be available free online.
In previous years you had to pay a small subscription fee to access
them.

But the biggest plus of JavaOne, like any conference, is meeting
people with common interests. I brought back a densely-packed page of
notes about things people told me they'd like to see in the JMX API.
That should generate enough blog material to last me to autumn.

Here's a terse summary of some of the main questions and
requests.

Metadata repository. Today you can query an MBean Server
to find out the management interface of any MBean registered in it.
But often you would like to find out the management interface ofall possible MBeans, even ones that aren't currently
registered. That would allow you to know what classes you can give tocreateMBean. Some systems
like CIM/WBEM
already support metadata query so adding this facility to the JMX API
would make it easier to implement those systems on top of it.

Federation and aggregation. The JMX Remote API provides a
good solution for a single client connecting to a single server. But
what if the client wants to manage a large number of servers? The
solution proposed for JMX API 2.0 is
href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072476">
cascading. But we probably also want to support some form ofaggregation. For example, if all of my 100 servers export an
"uptime" statistic, I'd like to be able to obtain an average uptime in
a single operation, rather than having to access 100 MBeans and
compute the average myself.

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
href="http://www.java.net/download/jdk6/doc/api/java/lang/management/ThreadMXBean.html#setThreadContentionMonitoringEnabled(boolean)">setThreadContentionMonitoringEnabled method in
href="http://www.java.net/download/jdk6/doc/api/java/lang/management/ThreadMXBean.html">java.lang.management.ThreadMXBean. But perhaps there
could be a more general convention, such as asetDetailLevel(int) method.

Generalized thread handling. There are a number of places
where the JMX API can create threads. A connector client needs a
thread to receive notifications from the server.
href="http://www.java.net/download/jdk6/doc/api/javax/management/monitor/package-frame.html">
Monitors and
href="http://www.java.net/download/jdk6/doc/api/javax/management/timer/package-frame.html">
timers need threads to do their periodic activities. A NotificationBroadcasterSupport can dispatch a
notification to listeners asynchronously rather than blocking the
sender. Could we have some centralized thread handling for all of
this? That might also fit better in contexts like Java EE where
random thread creation is frowned on or impossible.

Improved notification handling. Currently the JMX Remote
API has an imperfect guarantee for notification delivery: either you
receive all notifications you are subscribed for, or you receive an
indication that you may have lost some. (Notifications are not
silently lost.) But you might already have an infrastructure like JMS
or the
href="http://www.jini.org/nonav/standards/davis/doc/specs/html/js-spec.html">
JavaSpaces Service that guarantees reliable delivery. Could you
exploit this for your notifications? Could you roll your own
notification buffering?

Internationalizing descriptions. An MBean can have adescription for itself and for each of its contained
attributes, operations, etc. How can we arrange for these
descriptions to be internationalized? Ideally we'd like the client to
be able to
href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5072267">
communicate its locale to the server, and the server to send back
the descriptions appropriate to that locale. And we'd like some nifty
way to use annotations in an MBean interface to specify things like
href="http://www.java.net/download/jdk6/doc/api/java/util/ResourceBundle.html">
resource bundle names and resource keys.

More control over Standard MBean info. Now that a Standard
MBean can have a
Descriptor, it would be nice to be able to populate that
Descriptor with
href="http://www.java.net/download/jdk6/doc/api/javax/management/Descriptor.html">
annotations in the Standard MBean interface. Also, an
href="http://www.java.net/download/jdk6/doc/api/javax/management/MBeanParameterInfo.html">MBeanParameterInfo has a name, but that name is
always p1, p2, etc for a Standard MBean. It
would be nice to be able to specify the name with an annotation.
There are similar cases, like the
impact of an operation.

Annotations instead of MBean interfaces. A theme I heard
a lot was that people would like to be able to specify the
management interface of a class by using annotations rather than
having to create a separate MBean interface. For instance, you might
say

@Management

public long getUptime() {...}

in your class to define an Uptime attribute.

PropertyEditor for attributes. I heard
conflicting views on this one. One person thought it would be great
if the Descriptor for an attribute could specify a
href="http://www.java.net/download/jdk6/doc/api/java/beans/PropertyEditor.html">PropertyEditor
for it. Then a management console could allow you to view or edit
that attribute in some fancy way. Another rather more utilitarian
person thought it was a good thing developers couldn't do this because
it meant they would do more productive things with their time
instead!

MBean lifecycle support. The JMX API allows an MBean to
know when it is created and destroyed through the MBeanRegistration interface. But often there's a
distinction between creating the MBean and starting it, and between
stopping it and destroying it. It could be good to have a standard
interface with start() and stop() methods
that MBeans could implement.

Transactions. It would be good if the JMX API had some
form of transactions. Perhaps not the full
href="http://en.wikipedia.org/wiki/ACID">ACID properties, and
perhaps requiring MBeans to be transaction-aware if they want to
export transactional semantics, but that would still be good.

"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?

Tomcat. So just how do you create your own MBeans in a
Tomcat server, and how do you connect to them with
href="http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html">
jconsole?

Now, in fairness I should say that the snapshot of the JMX API that
you can see on
href="http://www.java.net/download/jdk6/doc/api/">java.net is
basically what you will get in Mustang (JDK 6) when it comes out. The
stuff listed above will almost entirely be addressed in Dolphin (JDK
7) at the earliest. There are already some nifty new JMX API features
in Mustang; some of the main ones were listed in a recent
href="http://java.sun.com/developer/technicalArticles/J2SE/Desktop/Mustang_build39.html#JMX">
java.sun.com feature.

In future entries here, I plan to talk about many of the above
items in more detail, and in many cases explain how you can get some
or all of the functionality using the existing API.