JMX - an answer to application manageability issue

JMX offers three valuable features:

Spring source logoRunning application manageability is a feature that is often forgotten about on a project, not only by the development team, but also by the customer when defining the requirements.

A good application is one that fits business requirements, is developed in compliance with quality criteria,  is stable and scalable etc..

A very good application also addresses operational needs. And one of these is the ability to easily control and monitor the running application, in real-time.

Lacking the capability to control and monitor usually results in reduced up-time. By monitoring real-time business and technical indicators, problems can be detected before they occur. The application can then be controlled and configurations changed without interrupting or stopping it.

Http servers, application servers and Java Virtual Machine (JVM) provide out-of-the-box management features, but these are usually of a technical and low level nature, and do not allow for accurate monitoring (Http access logs, memory usage, database connections etc..).

One great solution is to add the Java Management Extensions (JMX) services to your applications. JMX is a standard way of exposing services and contains a built-in JVM service, including the graphical JMX console (jconsole) and most of the monitoring applications provide out-of-the box JMX connectors.

JMX offers three valuable features:

  • MBean managed attributes access : read access on Java class managed attributes
  • MBean managed operations: managed Java class methods invocation, including setters methods
  • MBean notification : managed Java class ability to send notifications to JMX listeners

These features provide hot deploy configuration management ability and application or business dedicated metrics.
Personally I usually use JMX to provide metrics on the access and response time of high and medium level services (external services such as web services or EJB, DAO, interfaces with external systems..), and sometimes some useful statistics, usually defined in conjunction with the production operators. I also use JMX to control some service parameters, such as logging level.

You may think "That sounds great, architects always have great ideas but they do not have to suffer the process of implementing them!". But in this case there is an easy, straightforward and powerful solution: Spring.

I have created a short example to demonstrate how simple it is, and to show that it is possible to add the JMX feature to an existing service without modifying its source code. In this example I have three classes: the service class (ServiceBean), with a single service method and an attribute with getter/setter, and two MBeans - one to access the getter/setter method to control the service behaviour, and one to monitor the service statistics.

JMX example class diagramThe example implementation is a Maven project using Spring-JMX to create the MBeans, and Spring-aop to monitor the service without modifying its source code. The source code is really straightforward.

In order to keep it simple, the Spring configuration starts a dedicated JMX service to register the MBeans, so there is no need for an application server to run the test.

To test the example, just lanch the JUnit test case ServiceBeanTest. Then launch the JMX console with the following command line:

jconsole service:jmx:rmi://localhost/jndi/rmi://localhost:10099/Pipeline


Digital news!

Are you as digitally addicted as we are? We can supply you with a regular dose of digital news. Simply sign-up, or click to Follow us online.

About the author

Jacques Desmazières
Jacques Desmazières

J2EE/Java senior consultant. Expert in Software architecture and technical design, and involved in the b-i quality commitee. Before working for blue-infinity he was the technical director of a banking software editor on the French Riviera and also spend some years as a system integration consultant.