Specification: system sensor
Requirements
In complex Java applications performance problems can occur due to various factors. These problems should be detected and retaliatory actions performed. Monitoring the cpu usage (per core), the amount of total and free physical memory or the process cpu time are only a few points.
Monitoring should be possible with little impact on the design of the instrumented application. Instrumenting the VM would give us informations about such as the number of classes loaded, uptime of the JVM, the amount of memory consumed, number of threads running and deadlock detection. Another point would be the monitoring of the runtime stack.
It would be an advantage if the monitoring agent doesn't need to know anything about the application to instrument. Due to that, we would achieve an encapsulation. It should be considered in which intervals the monitoring happens and what the trigger is. The amount of the instrumentation should also be configurable (whole application or only pieces).
Approach
There are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:
- Monitoring and management API enhancements
- Official support for an improved graphical monitoring tool called JConsole
- Enhanced instrumentation of the Java virtual machine (JVM)
With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.
ere are a few possible ways to achieve the points listed above. Java SE 6 provides an in-depth focus on performance, offering expanded tools for managing and monitoring applications and for diagnosing common problems. The improvements include:
- Monitoring and management API enhancements
- Official support for an improved graphical monitoring tool called JConsole
- Enhanced instrumentation of the Java virtual machine (JVM)
With this monitoring and management APIs it's possible to get extended informations about the VM such as current threads running, heap state or the memory usage. But there is one thing that can't be done with pure Java. That's where the JNI (Java Native Interface) comes into play. With the JNI it's possible to get informations like the cpu usage directly from the underlying OS.
JMX
The Java Management Extensions (JMX) API is a standard API for management and monitoring of local and remote applications, devices, services, and the Java virtual machine. JMX became a standard part of the Java platform in in J2SE 5.0. Using JMX technology, a given resource is instrumented by one or more Java objects known as Managed Beans (MBeans). These MBeans are registered in a core managed object server (MBean server) that acts as a management agent and can run on most devices enabled for the Java programming language.
JMX technology enables Java applications to be managed without heavy investment: A JMX technology agent can run on most Java technology-enabled devices, thus Java applications can become manageable with little impact on their design. A Java application simply needs to embed a managed object server and make some of its functionality available as one or several managed beans (MBeans) registered in the object server; that is all it takes to benefit from the management infrastructure.
The architecture of JMX is shown below 
At the instrumentation level components called MBeans provide the application-specific management information. The MBeans provide the essential visibility and control for managing applications.
- The Agent level (MBean server) interfaces to the MBean components and provides a management interface to these components. The MBean Server is the key component in this layer, and provides a set of management functions useful to managing MBeans.
- The Connector Level consists of one or more connector (or protocol adaptor) components that provide access to remote management systems. Depending on the protocols supported by the JMX implementation, remote managers supporting SNMP, HTTP, or other management protocols can access the management information and control exposed by the MBeans for each application. Multiple management systems using different protocols can now simultaneously access the application management capability.
- With the management console (JConsole) it's possible to inspect and interact with MBeans as well as set any properties and invoke operations. JMX does not have a graphical user interface, but the informations we're getting out of the JMX Agent can also be used by other clients such as inspectIT
- Advantages of JMX
- fully integrated since J2SE 5.0
- can be used for out-of-the-box management of the Java VM
- Disadvantages of JMX
- no direct access to the underlying OS (for cpu usage)
- needs more implementation effort for Java 1.4
JNI
The Java Native Interface is needed for getting informations like the cpu usage of der underlying OS. It's impossible querying for cpu usage with pure Java so we need to go through the JNI to call native methods. Getting the informations out of Windows it's needed to compile the DLLs with a C-Compiler and under Linux it's needed to compile the .so (shared objects) files.
The architecture of JNI is shown below: 
- Advantages of JNI
- direct access to OS resources
- native code is faster than Java code
- Disadvantages of JNI
- subtle errors in the use of JNI can destabilize the entire JVM in ways that are very difficult to reproduce and debug
- no garbage collection for the JNI side
- portability