JMX, MXBeans – random thoughts and ideas

 

JMX has been around for a while. A very common use for JMX is to add it as a debug interface to a web application (https://rterp.wordpress.com/tag/mxbean/). The truth is that JMX is much more than that.

 

The core of JMX is MBean’s that are created in your application and can then be manipulated via the JMX framework. The concept of JMX reminds me of the DCOM of Microsoft architecture and CORBA (see https://jcp.org/en/jsr/detail?id=70 for a bridge between the two). In essence you create an MBean on the server (in the MBeanServer), and you can then access this information from any other machine.

 

The objects in JMX are organized in an ObjectName, which is a tree hierarchy of names. This concept is actually very similar to the SNMP MIB structure.

 

JMX supports attributes, operations and notifications. I have seen companies build full infrastructures of application monitoring on top of JMX (including synchronizing information between machines via JMX). Since you have attributes you can save state within the MBean. With the operations you can have method actions externalized, and with the notification you can have external client register for events without the hassle of creating a message bus or structure for notification (of course spring support of all JMX functionality: http://docs.spring.io/spring-integration/docs/2.0.0.RC1/reference/html/jmx.html).

 

Since the concept of the JMX is very open, multiple adapters have been created around the JMX ecosystem.  Java comes with the JConsole application, so you can easily manage your MBeans even remotely. There are HTML adapters, and even SNMP adapters. So if you have a center of data that you need to share with multiple clients in multiple formats you should have a look at JMX:

 

 

 

 

 

If you need export you data from JMX to other platforms (like GraphIte  or Gangila) there is a nice package called JMXTrans that comes with some build in  writers and a framework to create new ones (https://code.google.com/p/jmxtrans/wiki/IntroductionToJmxTrans). 

 

If all you need is to pass the information over http protocol that you can have a look at jolokia (http://www.jolokia.org/).  

 

Since is seems for some there is confusion between the two frameworks, both authors answered in the following question on the stackoverflow site: http://stackoverflow.com/questions/10151536/what-is-the-difference-between-jolokia-jmxtrans-when-to-choose-one-over-the

 

MXBean

Any class can be added to the JMX MBeanServer. If all the external actions (attributes, operations, notifications) use basic java types then you have no problem. You can use a self-written class, though the reading client must have this class in its classpath – a big constraint. To solve this issue JMX added the MXBean (http://docs.oracle.com/javase/7/docs/api/javax/management/MXBean.html) to support “open” types of java objects.

 

Oracle: An MXBean is a type of MBean that references only a predefined set of data types.

In other words by constraining the data types of you bean, JMX can now translate you “private classes” to a generic format using CompositeData and TabularData classes.

 

To use an MXBean you either implement an interface with MXBean suffix or use the @MXBean annotation. The other constraint of MXBean is that you must add the annotation @ConstructorProperties to your constructors.

 

When you use a concrete class in your code the MBeanServer will serialize the class into a generic class of the types:  CompositeData (http://docs.oracle.com/javase/7/docs/api/javax/management/openmbean/CompositeData.html), TabularData http://docs.oracle.com/javase/7/docs/api/javax/management/openmbean/TabularData.html.

 

These classes are similar to a hashmap, though they include information as to the type of each field. This way and client that supports the JMX MXBean can serialize this object and use it. If your client has your propriety class then you can easily serialize the MXBean back to your class.

 

The MBeanServer will validate the field types of all MXBean’s to make sure you did not use invalid types. Since you can externalize complex classes, the MXBeanServer will serialize it to one of the classes in the javax.management.openmbean package.

 

For most cases you do not need to add any special code, since one the MXBean is registered in the MBeanServer any access to this server via a client, the server will property serialize the class. The only case that you need to write code is the case of notification and using the user data object.

Notifications

To send a broadcast notification you create the Notification Object (http://docs.oracle.com/javase/tutorial/jmx/notifs/) The notification object has some basic field like type, source, message and other fields. If you want to add your own typed payload you need to use the User Data object. For complex classes you should be using the CompositeData or the TabularData. 

 

To create this class you need to specify all the fields and their types, for example:

String[] names = {"poolName", "usage", "count" };

 

Object[] values = { null, null, null };

 

OpenType[] types = { SimpleType.STRING, memoryUsageCompositeType,

 

            SimpleType.LONG };

 

CompositeType compositeType = getCompositeType(names, types);

 

CompositeData data = new CompositeDataSupport(compositeType, names, values);

 

 

 

This is obviously not very type safe or developer oriented. The class we would like to use would be like:

public class PoolUsage {

 

       String poolName;

 

       MemoryUsage usage;

 

       Integer count;

 

}

 

To solve this issue we will use a trick with the MBeanServer. As stated above if your class is an attribute or used in an operation the MBeanServer will do all the transformations for you. The problem is in the User Data scenario where you need to manually add the class. The trick is to have a helper class that inherits from StandardMBean. This class will have an internal field with your typed class. The trick is then when you want to serialize your class, you create the help class, assign the field with the value and the get the same field but via the getAttribute of the StandardMBean. This way the JMX framework will do the serialization for you. The other direction is the same. You create the helper class and assign the field using the JMX setAttribute (setting the composite data you got in the notification) and the retrieve the specific class using the standard getter.

 

Sample code:

 

public class PoolUsageSerializer extends StandardMBean implements PoolUsageInterface{

 

       private final static String ATTRIBUTE_NAME = "PoolUsage";

 

       protected PoolUsage poolUsage;

 

 

 

       public PoolUsage getPoolUsage() { return poolUsage;    }

 

 

 

       public void setPoolUsage(PoolUsage poolUsage) { this.poolUsage = poolUsage; }

 

 

 

       public PoolUsageSerializer() { super(PoolUsageInterface.class, true); }

 

 

 

 

 

       public static Object serialize(PoolUsage poolUsage) {

 

              PoolUsageSerializer me = new PoolUsageSerializer();

 

              me.setPoolUsage(data);

 

              return me.getAttribute(ATTRIBUTE_NAME);

 

       }

 

 

 

       public static PoolUsage deserialize(Object userData) {

 

              PoolUsageSerializer me = new PoolUsageSerializer();

 

              Attribute attr = new Attribute(ATTRIBUTE_NAME, userData);

 

              me.setAttribute(attr);

 

              return me.getPoolUsage();

 

       }

 

}

 

 

For more information see:

https://weblogs.java.net/blog/emcmanus/archive/2006/02/what_is_an_mxbe.html

 

Security

JMX also supports the option to secure the server with user name and password. You can also assign roles (read/write) per user, and even secure communications via ssl. For securing your JMX on tomcat see http://tomcat.apache.org/tomcat-7.0-doc/monitoring.html.