JMX, SNMP, Java, etc...

JConsole and VisualVM have made it very simple to access MBeans in a remote target VM. There's also a lot of blogs and documents that explain how to access remote MBeans programmatically.

But how do you access local MBeans registered in your own JVM?

Last Friday I finally upgraded to firefox 3.0.1 on Solaris x86. After starting it, it quickly appeared that something was wrong: Firefox 3 was apparently unable to retrieve any of the passwords I had saved with the previous Firefox 2 version!

Yesterday my colleague Shanliang asked me whether there was a way to see which files had been modified in the changesets that would be pulled in by 'hg pull', and whether they would conflicts with the files currently being edited in his workspace.

... So many words I couldn't even put them all in the title...

I've been asked several times how to make my example of javaagent which starts a firewall friendly JMX RMI Connector work on JDK 5. Well, here is how. However, beware of the catch: if you use SSL and want to connect with JConsole then you need to use Java 6 JConsole on the client side.

The first stable release of OpenDS is out! This LDAP Server written in Java can be monitored both through JMX and SNMP.

No, rest assured - I have not conjured up some kind of new unfathomable hybrid beast from Dante's Seventh Hell... More prosaically, I have simply put together a small JavaScript slide show from some JMX 2.0 Namespace slides presented by Eamonn at JavaOne 2008.

Although it might not be a very good idea to define your management model based on how it will be displayed by a given GUI, such as that provided by JConsole or VisualVM, I believe it is nonetheless interesting to explore the various ways in which a complex type such as a Map<String,Integer> could be modeled and exposed through an MXBean attribute.

... while working on uncommitted changes.

Sometimes when you are working on a fix - or an RFE, you'd like to sync-up with your parent's repository and pull any changes it contains without having to commit your own work in progress. Here is my own recipe - direct from my mercurial cookbook.

Jean-Francois Denise has just contributed a very interesting source add-on contribution to Project OpenDMK. It is composed of two small java classes which provide a generic RESTful access to MBean attributes.

Recently I was asked how to do "registerMBean" in a remote JVM, from a remote JMX client. The MBeanServerConnection doesn't expose any registerMBean method, and for good reasons.

After several years of resistance, I have finally surrendered to modernity: last week I bought a mobile phone.

... so I thought I'd drop a line. I have just uploaded a small set of slides of a high level presentation of project OpenDMK on the project's home page.

JMX is a wonderful tool to monitor and troubleshoot running applications. The new JDK 6 Attach API makes it very easy to attach to a running Java process, and start a JMX agent that will expose monitoring and configuration data to JMX consoles - like JConsole. However, there are some situations where you wish to start a JMX agent on demand, explore the monitoring data or diagnose the probable cause of an observed problem, and then close your JMX agent, leaving the application just how you found it.

In this post, I will discuss a means by which you can upload and start such a remotely stoppable JMX agent. Here is how.

The source code for OpenJDK is now available in Mercurial repositories. These repositories are organized into mercurial forests. If you are eager to work on the OpenJDK code, you will want to install the forest extension for Mercurial. Here is how I did it on my windows test machine.