JMX: Difference between revisions
| Line 121: | Line 121: | ||
===<tt>NotificationBroadcasterSupport</tt>=== | ===<tt>NotificationBroadcasterSupport</tt>=== | ||
{{External|https://docs.oracle.com/en/java/javase/13/docs/api/java.management/javax/management/NotificationBroadcasterSupport.html}} | {{External|https://docs.oracle.com/en/java/javase/13/docs/api/java.management/javax/management/NotificationBroadcasterSupport.html}} | ||
<code>NotificationBroadcasterSupport</code> implements [[#NotificationEmitter|NotificationEmitter]] interface. | |||
===JMX Notification Playground Example=== | ===JMX Notification Playground Example=== | ||
Revision as of 21:31, 18 February 2020
External
- https://docs.oracle.com/javase/8/docs/technotes/guides/jmx
- JMX API https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/spec.html
- http://docs.oracle.com/javase/8/docs/technotes/guides/management/mxbeans.html
Internal
Overview
Subjects
Specifications
Concepts
MXBean
An MXBean is a kind of MBean. For more details see
Open Type
The Platform MBean Server
The platform MBean server is an MBean server that is built into the JVM. It can be accessed and shared by all managed components that are running in that JVM. It can be retrieved with java.lang.management.ManagementFactory.getPlatformMBeanServer(). The platform MBean server was introduced in Java 5. javax.management.MBeanServerFactory can be used to create a different MBean server, or look up an already existing MBean server (that is not the platform server).
For a code example of how to look up the platform MBean server and how to register an arbitrary MBean to it, see
Platform MXBeans
A platform managed object is an JMX MXBean deployed on a JVM's platform MBean server. Platform MXBeans expose monitoring and management capabilities for components of the Java platform. Platform MXBeans only use a set of basic data types, so a JMX management application and the platform MBeanServer can interoperate without requiring classes for MXBean specific data types. The data types being transmitted between the management client and the JMX server are open types and this allows interoperation across versions.
Common platform MXBeans:
Thread Monitoring and Management
Memory Monitoring and Management
O/S Level Runtime Metrics
Classloading Metrics
Other Monitoring and Management Components
Remote Access to a JMX Server
The JMX specification includes built-in support for accessing JMX servers remotely. Remote access details are described in the Section III of the specifications "JMX Remote API Specification".
An application that wishes to access a remote JMX server must create a session. The session allows for multiple, successive connections. The underlying mechanism that insures the client/server communication over the network is called a connector. A connector consists of a connector client and a connector server. The connector server is attached to the MBean server and listens for connection requests from clients. The connector client exposes essentially the same interface as the MBean server serviced by the connector. The connector client usually lives in a different JVM from the connector server, on a remote host. The connector client is connected to exactly one server. The connector client is represented by an object that implements JMXConnector.
The standard implementation required by the specification involves RMI (Remote Method Invocation). For an implementation to be spec-compliant, must expose an RMI-based remoting implementation. Optional protocols can be supported.
The JMX session does not have state on the server, each request is independent from the previous one.
The client obtains an object that implements MBeanServerConnection interface. The interface is similar to MBeanServer, which would be used if the client code was collocated with the MBean server in the same JVM. MBeanServerConnection is the parent of MBeanServer, which contains the same methods, with the exception of a small number of methods that only make sense for local access. This similarity allows to write client code that works identically when accessing a local server and a remote server. If the server operation throws an exception, the connector arranges for the client's invocation to get the same exception.
The connector server has an address used by the clients to establish connections to the server. The address is described by the JMXServiceURL class. Example:
service:jmx:jmxmp://example.com:9876
The address is provided to a JMXConnectorFactory instance, which creates the connection:
JMXConnector jmxConnector = JMXConnectorFactory.connect(jmxServiceURL);
Once connected, the JMXConnector instance can be used to get a MBeanServerConnection instance, which in turn can be used to interact with the remote JMX server as it would reside locally:
MBeanServerConnection jmxServerConnection = jmxConnector.getMBeanServerConnection();
Object attributeValue = jmxServerConnection.getAttribute(objectName, attributeName);
A practical example of how to programmatically access a remote WildFly JMX bus - or any remote JMX bus for that matter - is available here:
JMX Notifications
The JMX API defines a mechanism that enables MBeans to generate notifications. Typical use cases are signaling a state change, a detected event or a problem.
To generate a notification, an MBean must implement NotificationEmitter or extend NotificationBroadcasterSupport.
To send a notification, a Notification instance or one of its subclasses must be created and passed to NotificationBroadcasterSupport.sendNotification().
To receive a notification, TODO.
Notification
Sub-classes: AttrributeChangeNotification
Every notification has a source, which is the Object Name of the MBean that generated the notification.
Every notification has a sequence number, which can be used to order notifications coming from the same source. The sequence number can be zero, but preferably the number should be incremented for each notification emitted by a given MBean.
NotificationEmitter
NotificationBroadcasterSupport
NotificationBroadcasterSupport implements NotificationEmitter interface.