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?

... 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.

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.

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.

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.

In his blog, Ingo Rockel posted about a nice Thread Dump plugin for JConsole. Out of curiosity, I decided to give it a try.

This post explains how you can configure your Java application to export a single port using JMX RMI Connector Server over SSL. This is particularly useful when your application is located behind a firewall, because you will only need to let through a single port. However, using a single port when SSL is enabled requires a little care, because it can only work if the same RMI Socket Factories are used everywhere: indeed the same port cannot be shared by two different RMI Socket Factories. So at the risk of boring you, here is my third post on the subject.

Dmitri Maximovich has written an excellent article about how to monitor JVM memory using MRTG.

In my previous blog entry, I have talked about how to take advantage of java agents in order to start a custom JMX Connector in a Java application, without modifying the application. This is particularly useful when you need to monitor Java applications which are located behind a firewall. In that case, it makes it possible to write a java agent that will start a RMI connector configured in a firewall-friendly manner. However, there's a catch. This is what this entry is about.

In a recent comment on my blog about Troubleshooting Connection Problems in JConsole I was asked the following question:

Can you simply explain how run jconsole on a client machine to connect to an unmodifiable applicaton that run on a server. One and only one port on the server is open though firewall for managing the application.

Here is how.

How to use JMX to programatically retrieve the information that JConsole displays is easy. Here is a small JMX Client Program that shows how you can programatically retrieve the JVM Management and Monitoring information from a remote JVM.

Q: When is a Standard MBean not a Standard MBean?
A: When it's a StandardMBean.

In this article I will give a few tips concerning the StandardMBean class, and in particular, when and why it becomes interesting to use it.

The JMX forum on SDN is a lively place. Recently, Athahar was trying to expose a POJO resource through JMX - and quite naturally, decided to try out doing this with a ModelMBean. However, ModelMBeans are not the only way to this - and here are a few thoughts, which borrow heavily on some of Eamonn's most recent blog entries.