Eamonn McManus's Blog

Eamonn McManus is the technical lead of the JMX team at Sun Microsystems. As such he heads the technical work on JSR 255 (JMX API 2.0) and JSR 262 (Web Services Connector for JMX Agents). In a previous life, he worked at the Open Software Foundation's Research Institute on the Mach microkernel and countless other things, including a TCP/IP stack written in Java. In an even previouser life, he worked on modem firmware in Z80 assembler. He is Irish, but lives and works in France and in French. His first name is pronounced Aymun (more or less) and is correctly written with an acute accent on the first letter, which however he long ago despaired of getting intact through computer systems.

JMX Namespaces now available in JDK 7

The JMX Namespace feature has now been integrated into the JDK 7 platform. You can read about it in detail in the online documentation for javax.management.namespace. Here's my quick summary.

Namespaces add a hierarchical structure to the JMX naming scheme. The easiest way to think of this is as a directory hierarchy. Previously JMX MBeans had names like java.lang:type=ThreadMXBean. Those names are still legal, but there can now also be names like othervm//java.lang:type=ThreadMXBean.

The othervm "directory" is a JMXNamespace. You create it by registering a JMXNamespace MBean with the special name othervm//:type=JMXNamespace. You specify its contents via the sourceServer argument to the JMXNamespace constructor.

There are three typical use cases for namespaces. First, if you have more than one MBean Server in the same Java VM (for example, it is an app server, and you have one MBean Server per deployed app), then you can group them all together in a higher-level MBean Server. Second, if you have MBean Servers distributed across different Java VMs (maybe on different machines), then again you can group them together into a "master" MBean Server. Then clients can access the different MBean Servers without having to connect to each one directly. Finally, namespaces support "Virtual MBeans", which do not exist as Java objects except while they are being accessed.

There's much more to namespaces than I've described here. Daniel Fuchs is the engineer who did most of the design and implementation work on namespaces, and I expect he will have more to say about them in the near future on his blog.

[Tags: jmx jdk7 jsr255]

Event Sevice: subscribe to a set of MBeans (registered or non-registered)

[Tags: jmx jdk7 jsr255.]

Dropping proposed features from the new JMX API

Yesterday I cleaned up the umbrella bug that lists the various things we are planning for version 2.0 of the JMX API, which is the version that should be included in Java SE 7. Here's a list of the things we were thinking of doing but are not now planning to.

In some of these cases, we realized after discussion in the Expert Group that the proposed feature was either not practical or too hard to nail down. For example, support for persistence would be good. But what would it look like? Would we give you some way to take a snapshot of every MBean? How would that snapshot be represented? How would it be restored? Or would we have a way for an MBean to define its own persistence explicitly? Then what could we usefully define that an MBean can't already do today?

In other cases, a reluctant engineering decision was taken because, though the feature would be useful, it would not be useful enough to justify the engineering work to specify it, implement it, and write spec conformance tests for it.

Here's the list, with explanations:

• 4718350 Wildcard support in notification filter

  This is superseded by the new class QueryNotificationFilter, which is more general.

• 5108792 Add abstract base class to make coding DynamicMBeans easier

  Although this would occasionally be useful, the main thing it could do would be to implement getAttributes in terms of getAttribute and setAttributes in terms of setAttribute, and in practice people don't code Dynamic MBeans often enough for that to justify a new class.

• 4718269 Model MBean should be extended to support EJB handles

  This one was never on the cards, because this API is part of the Java SE platform, and EJBs are part of Java EE.

• 4718298 ModelMBeanInfo.getConstructor(String) could be added

  ModelMBeanInfo is an interface so adding a method to it would be an incompatible change. (Existing classes that implement this interface would not have the new method.)

• 6176837 TabularDataSupport.entrySet() should prevent calls to Map.Entry.setValue on returned set elements

  I logged this one a few years ago for aesthetic reasons. The spec basically says "don't do this or things will break". A good spec should never say that. It should say "if you try to do this operation that would break things, you will get an exception". But in practice this is in a pretty obscure corner of the API and making it generate the exception would be a nontrivial amount of work, and probably imply a performance penalty, so the change was hard to justify.

• 5031385 m-let file format should be XML

  Again MLet files are not a core part of the API so making this change would be hard to justify. What's more we'd probably have to work out how to support the previous almost-XML format and the new really-XML format at the same time, and that would be hard.

• 6323896 Support aggregation of multiple MBean Servers

  This is certainly something that we often see people needing, but the Expert Group discussion concluded that it would be very hard to define something that would be general enough to be useful while still simple enough to be understandable.

  I think this is still an interesting area for future work, but it will unfortunately not be part of the JMX 2.0 API.

  We will still support federation, meaning that you can group several MBean Servers into a single "master" MBean Server. But we will not support for example a predefined way to have an MBean in the master that shows the average of a certain attribute across each of the federated MBean Servers. (Users should still find it easy to address any given case by coding it explicitly.)

• 6323795 Metadata repository for JMX API

  The idea here is that you can see the metadata for every JMX MBean that currently exists (for example, its operations and attributes). But you can't see the metadata for every MBean that might exist. It would be great to be able to browse the MBean class hierarchy independently of instances.

  Although this is not planned for the 2.0 API, it would be an interesting project to use the new Namespace support to implement a namespace with one MBean instance for each class of MBean that exists (discovered perhaps by looking through the jars in the classpath). The MBeanInfo of each of these "template MBeans" would be the MBeanInfo that each instance of the corresponding class would have, or as near to that as we could deduce. (This idea is due to Nick Stephen.)

• 5108724 Add support for persistence to JMX API

  I talked about this above.

• 6323764 Add support for client sessions to JMX API

  The idea here was that a client could create an object on the server that represented some part of its state, for example a transaction or a set of notifications that the client is interested in or a long-running operation. However, the Expert Group considered that most of these cases could be addressed using "client contexts", a new feature where the client can communicate a context to the server with every operation. This context could be a locale or a transaction id or whatever.

None of these decisions is completely irreversible of course. But at this stage I think anyone with a very strong desire to see any of the departed features brought back would need to volunteer to do all the relevant engineering work!

[Tags: jmx jdk7 jsr255]

JMX Event Service now available in JDK 7 snapshots

The new Event Service that is part of version 2.0 of the JMX API is available in the latest snapshot of the JDK 7 platform. The package description for the new javax.management.event package summarizes what it is for and how to use it.

The description there starts like this:

This package defines the Event Service, which provides extended support for JMX notifications.

The Event Service provides greater control over notification handling than the default technique using MBeanServer.addNotificationListener or MBeanServerConnection.addNotificationListener.

Here are some reasons you may want to use the Event Service:

• To receive notifications from a set of MBeans defined by an ObjectName pattern, such as com.example.config:type=Cache,*.
• When the notification-handling behavior of the connector you are using does not match your requirements. For example, with the standard RMI connector you can lose notifications if there are very many of them in the MBean Server you are connected to, even if you are only listening for a small proportion of them.
• To change the threading behavior of notification dispatch.
• To define a different transport for notifications, for example to arrange for them to be delivered through the Java Message Service (JMS). The Event Service comes with one alternative transport as standard, a "push-mode" RMI transport.
• To handle notifications on behalf of MBeans (often virtual) in a namespace.

The Event Service is new in version 2.0 of the JMX API, which is the version introduced in version 7 of the Java SE platform. It is not usually possible to use the Event Service when connecting remotely to an MBean Server that is running an earlier version.

As with everything else in the new JMX API, we're always keen on hearing feedback, which you can add as a comment here or send to jmx-spec-comments@sun.com.

The principal designer of the new Event Service is Shanliang Jiang, and he'll probably have some interesting things to say about it, which I'll link to from here.

[Tags: jmx jdk7.]

Playing with the JMX 2.0 API

Version 2.0 of the JMX API is being defined by JSR 255. I've written about some of the features in the new API before. They are trickling into the JDK 7 sources over time, so you can now play with some shiny new things. Here's a description of what they are, and how you can even access them from JDK 6 if you are brave.

As you probably know, the JDK 7 platform is being developed in open source, which means that you can see the changes as soon as the JMX team commits them.

You can browse the current mainline JDK 7 sources directly from the Mercurial repository, at http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip.

These sources correspond to the Javadoc snapshot at http://download.java.net/jdk7/docs/api/index.html, and to the JDK 7 snapshot binary at http://download.java.net/jdk7/binaries/.

If you download the JDK 7 snapshot binary, you can use it the same way you would use any other JDK installation. Of course, this is work in progress, so don't use it for anything critical. But it tends to be surprisingly stable, and I often use it to run NetBeans, for example.

Recent JMX API changes in the JDK 7 sources

You can also see all of the changes that have gone into the JDK 7 sources at http://hg.openjdk.java.net/jdk7/jdk7/jdk/shortlog. At the time of writing, one interesting thing you will see there (if you find the JMX API interesting) is this:

Changes that are on the way

For a project as big and important as the JDK 7 project, there's a lot of extra engineering that has to happen between the time the JMX team pushes a change into a publicly-visible repository and the time that change actually shows up in the snapshots. I think of the changes as being "in the pipes" during this time. You can see our changes as soon as we push them by looking at http://hg.openjdk.java.net/jdk7/tl/jdk. (Here, tl stands for "tools and libraries", which is the subproject where the JMX API lives.)

At the time of writing, this will show the change
5108776: Add reliable event handling to the JMX API
which is the new Event Service. You might have already seen this in the Early Draft Review of the JMX 2.0 API, but if not it will eventually appear in the Javadoc snapshots in the package javax.management.event, or if you can't wait you could always read the source of the javadoc for that package.

There are two other chunks of functionality that should be showing up in the next couple of months, one big and one somewhat smaller. The big one is namespaces. The smaller one is the stuff that will build on namespaces to support "client contexts" (also described in the slides at that link) and localization of descriptions in MBeanInfo.

Once those are in we will be looking at a smallish subset of the various RFEs open against the JMX API. Now would be a good time to agitate for anything you particularly want to see.

Using the JMX 2.0 API with the JDK 6 platform

Using the JDK 7 sources, you can in fact build a jar with just the JMX classes and run that with a JDK 6 installation. Of course this is even less supported than running a JDK 7 snapshot, but once again assuming you're not using it for anything critical here's how you would go about it.

First download the JDK 7 sources, either using Mercurial if you have it, with a command like this...

hg clone http://hg.openjdk.java.net/jdk7/jdk myjdk

...or by downloading the sources from http://download.java.net/jdk7/. The "JDK 7 Source under the JRL license" link on that page is a jar which you download and run using a command like this...

java -jar jdk-7-ea-src-b32-jrl-04_aug_2008.jar

Now cd to the jdk subdirectory of the sources, if you downloaded the bundle, or into the Mercurial repository you cloned if you did that (you only cloned the jdk subdirectory). Run this command...

ant -f make/netbeans/jmx/build.xml

If it works, it'll make you a jmx.jar in dist/lib and that's what you can use with your JDK 6 installation. (If it doesn't work, tell me what went wrong and I'll update the instructions here.)

Now you can use your new jmx.jar in either of two ways. The simplest is to make a directory called endorsed inside the jre/lib subdirectory of your JDK installation (if there isn't one already), and then drop jmx.jar into it. (I would recommend renaming it too, to something like jmx-2.0-snapshot-2008-08-06.jar.) But beware that if you do this you are replacing the JMX implementation for all users of that JDK installation!

The second way is to run your programs like this...

java -Xbootclasspath/p:/path/to/jmx.jar ...

Then only programs that are explicitly run in that way will be using the new JMX implementation.

Let us know how you get on

If you play with the new JMX API, or even if you are just browsing through it, we're very interested in hearing about your experiences. Feel free to add your comments here, or send mail to jmx-spec-comments@sun.com, or write a blog entry with tag "jmx". Thanks!

[Tags: jmx jdk7.]

October 2008

Search this blog:

Categories

Archives

September 2008
August 2008
May 2008
April 2008
February 2008
December 2007
October 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
July 2006
June 2006
May 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005

Recent Entries

JMX Namespaces now available in JDK 7

Event Sevice: subscribe to a set of MBeans (registered or non-registered)

Dropping proposed features from the new JMX API

This work is licensed under a Creative Commons License.