Skip to main content

JavaOne feedback about JMX technology

Posted by emcmanus on July 13, 2005 at 1:13 PM PDT

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 of
    all possible MBeans, even ones that aren't currently
    registered. That would allow you to know what classes you can give to
    createMBean. 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 of
    aggregation. 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 a
    setDetailLevel(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 a
    description 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.

Related Topics >>