Jmx connectors

Jmx connectors DEFAULT

JMX Series

The waterproof and extreme high temperature resistance characteristics of the JMX series makes it ideal for Medical, Instrumentation and Measurement applications. However, the plastic Push-Pull connectors can also be used in a diversity of other Industrial applications requiring a lightweight, yet durable harsh environment interconnect solution.

The JMX plastic Push-Pull connector series guarantees a reliable and secure connection with only two fingers. Connectors are available in 6 keys and 9 color identifying codes to avoid situations of incorrect mating.

Capable of over 2,000 mating cycles, the JMX connector series is also able to withstand steam autoclave sterilization per IEC 60601-1 (up to 200 cycles). In addition, it will protect your equipment from fluid ingress due to its IP68 attributes in mated and unmated conditions

The JMX Plastic Push-Pull connector is aesthetically and visually appealing to complement and blend with medical equipment designs. The curves of the coupling ring provides exceptional tactile comfort and an easy to handle grip design so that fingers will fit instinctively.


Remote JMX: Connectors and Adapters

One of the things that was most difficult for me to learn when first learning about Remote JMX was the difference between a JMX Connector and a JMX Adapter (also spelled Adaptor in many cases). Part of this confusion was a result from trying to understand the difference based on books written before the Remote JMX specification was written or finalized. Another part of the confusion is in the actual names. In this blog entry, I'll point to a few references and resources that I think best explain the JMX Connector and the JMX Adapter and then I'll go through some source code examples because I believe that using these in practice makes them easier to understand than simply reading the words.

The JMX 1.4 specification includes both "regular" JMX and remote JMX in a single, consolidated specification. Part III of this consolidated JMX specification is focused on Remote JMX and is called "JMX Remote API Specification." The first chapter in this Part III, Chapter 13, covers JMX Connectors in general and is followed by Chapter 14 focusing on the RMI-based JMX Connector and Chapter 15 focusing on the Generic Connector.

I think two sentences in Chapter 13 of the JMX 1.4 specification are particularly important to understanding JMX connectors:

1. "The client end of a connector exports essentially the same interface as the

MBean server."

2. "A connector consists of a connector client and a connector server."

Section 5.3 of the JMX 1.4 specification is called "Protocol Adaptors and Connectors" and covers basics of both adapters and connectors. Related to JMX connectors, this section makes the important observation that "A connector is specific to a given protocol, but the management application can use any connector indifferently because they have the same remote interface."

This section also clearly outlines differentiating characteristics of JMX Protocol Adaptors:

1. "Protocol adaptors provide a management view of the JMX agent through a given protocol. They adapt the operations of MBeans and the MBean server into a representation in the given protocol, and possibly into a different information


2. "Management applications that connect to a protocol adaptor are usually specific to the given protocol."

With the key characteristics of JMX connectors and protocol adaptors highlighted above, there are some quickly identifiable differences between the two. These differences may be most succinctly summarized in Daniel Fuchs's blog entry What is JMX?, where he states that JMX Protocol Connectors represent the MBeans to the remote client the same way they would be represented to a local client and that a JMX Protocol Adaptor adapts the server-side model to what the client expects.

JMX Protocol Connectors and JMX Protocol Adaptors both typically work with a single protocol. The difference between the two is that Adaptors massage the management interface for the client's benefit while the Connectors provide a protocol-independent API that is essentially the same as the local API.

The JMX Reference Implementation (the implementation of JMX included in Sun's Java SE 6 distribution) provides the one Connector required of the specification: the Remote Method Invocation (RMI) Connector. The JMX 1.4 specification only requires a JMX implementation to provide an RMI-based Connector, but the specification outlines an optional JMXMP-based Connector. For this example, I use the JMXMP (JMX Message Protocol) Connector provided by OpenDMK. The third JMX Connector used in this example is the JSR-262JMX Web Services Connector.

I now delve into some code samples to illustrate JMX Connectors versus JMX Adaptors. For simplicity, I have a single class that runs three types of JMX Connector Servers and also runs an Adapter Agent. This class is called JmxServerMain and its main() method is listed here first. main() Method

I will show the implementations of the methods called above later in this entry, but even this high-level look reveals clear and easily identifiable differences between Connectors and Adapters. Note that all three JMX Connectors can be treated the same and can take advantage of the same method. In other words, all three Connectors can be set up using the useJmxServiceUrlBasedConnector method. The Adapter, on the other hand, can not take advantage of the same method as the Connectors and must be set up with its own useHtmlAdaptor method. Note that this method name, useHtmlAdaptor, is specific to the adaptor involved.

The definition of the useJmxServiceUrlBasedConnector method is shown next.

JmxServerMain and its useJmxServiceUrlBasedConnector Method

The useJmxServiceUrlBasedConnector method shown above is generic and supports all types of specification-compliant JMX connectors provided to it. In fact, the only thing that differentiates one type of connector from another is the protocol embedded within the string that forms the JMXServiceURL. For connector management purposes, it is a recommended practice to register connectors themselves as MBeans and that is also done in this code.

We have now seen that the same generic code can be used to set up all the Connectors for Remote JMX access. In the example above, the RMI, JMXMP, and JMX Web Services Connector are all used this way. The next code listing shows the code for the useHtmlAdaptor method, which is also part of the JmxServerMain class. useHtmlAdaptor Method

The HTML Adaptor is not acquired with a standardized JMXConnectorServerFactory.newJMXConnectorServer call like the connectors were able to be acquired. Instead, the HtmlAdaptorServer is explicitly instantiated. The HTMLAdaptorServer used here is provided by OpenDMK.

All three JMX Connectors (RMI, JMXMP, and WS-JMX) can be connected to by JConsole or by any other standard JMX client. I'll first show the code for accessing these three connectors from a simple client.

How to choose a low-code development platform

  1. Extra large square outdoor planters
  2. Algorithms engineer jobs
  3. Craftsman industrial tools catalog
  4. Trailer hitches at tractor supply
  5. Msdn download center

Skip navigation bar

Chapter   5

Using JMX Connectors to Manage Resources Remotely

The Java Management Extensions Instrument and Agent Specification defines the concept of connectors. A connector makes a Java Management Extensions (JMX) technology MBean server accessible to remote Java technology-based clients. The client end of a connector exports essentially the same interface as the MBean server.

A connector consists of a connector client and a connector server. A connector server is attached to an MBean server and listens for connection requests from clients. A connector client is responsible for establishing a connection with the connector server. A connector client will usually be in a different Java Virtual Machine (Java VM) from the connector server, and will often be running on a different machine.

Many different implementations of connectors are possible. In particular, there are many possibilities for the protocol used to communicate over a connection between client and server.

A connector server usually has an address, used to establish connections between connector clients and the connector server. Alternatively, some connectors can provide connection stubs to establish connections. The way in which connections are established depends on the discovery and lookup technology that you use (see Chapter 6, "Discovery and Lookup Services").

This chapter outlines the different types of connector defined by the JMX Remote API specification and the protocols they use, in the following sections:

  • "RMI Connector": This standard Remote Method Invocation (RMI) protocol must be supported by every implementation that conforms to the JMX Remote API standard.
  • "Generic Connector": The JMX Remote API standard also defines an optional protocol based directly on TCP sockets, called the JMX Messaging Protocol (JMXMP). An implementation of the standard can omit the JMXMP connector, but must not omit the RMI connector. The Java SE platform does not include the optional JMXMP connector.

RMI Connector

The JMX Remote API standard defines a standard protocol based on RMI. The RMI connector must be present in every implementation of the JMX Remote API.

RMI defines two standard transports, the Java Remote Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP). The RMI connector supports both transports.

The RMI connector over JRMP provides a simple mechanism for securing and authenticating the connection between a client and a server. This mechanism provides a basic level of security for environments using the RMI connector. Note that the generic JMXMP connector provides a more advanced level of security.

You can improve on the basic security mechanism of the RMI connector over JRMP by using an RMI socket factory so that the connection between client and server uses the Secure Socket Layer (SSL).

Generic Connector

An optional part of the JMX Remote API, which is not included in the Java SE platform, is a generic connector. This connector can be configured by adding pluggable modules to define the following:

  • The transport protocol used to send requests from the client to the server, and to send responses and notifications from the server to the clients
  • The object wrapping for objects that are sent from the client to the server and whose class loader can depend on the target MBean

The JMX Messaging Protocol (JMXMP) connector is a configuration of the generic connector where the transport protocol is based on TCP and the object wrapping is native Java serialization. Security is more advanced than for the RMI connector. Security is based on the Java Secure Socket Extension (JSSE), the Java Authentication and Authorization Service (JAAS), and the Simple Authentication and Security Layer (SASL).

The generic connector and its JMXMP configuration are optional, which means that they are not always included in an implementation of the JMX Remote API. The Java SE platform does not include the optional generic connector.

User-Defined Protocols

While the RMI connector must be present in every implementation of the JMX Remote API, you can also implement a connector based on a protocol that is not defined in the JMX Remote API standard. A typical example of this is a connector based on a protocol that uses HTTP/S. Other protocols are also possible. The JMX specification describes how to implement a connector based on a user-defined protocol.


JMX Quick start example

Skip navigation bar

Chapter   3

JMX Connectors

This chapter introduces the concepts of standard and dynamic management beans (MBeans) and also shows how to use Java Management Extensions (JMX) technology to perform operations on MBeans, both locally and remotely.

Accessing Standard and Dynamic MBeans via the RMI Connector

This example demonstrates standard and dynamic MBeans only.

As seen in Chapter 2, "Essentials of the JMX API", a standard MBean is one that statically defines its management interface through the names of the methods it contains. A dynamic MBean implements a specific Java interface and reveals its attributes and operations at run time.

The JMX technology defines a connector based on RMI. The RMI connector supports the Java Remote Method Protocol (JRMP) transport, and optionally, the Internet Inter-Object Request Broker (ORB) Protocol (IIOP) transport. This connector allows you to connect to an MBean in an MBean server from a remote location, and perform operations on it, exactly as if the operations were being performed locally.

The purpose of this example is to demonstrate the implementation of a standard MBean and a dynamic MBean. It also shows how to perform operations on them, both locally, and remotely through an RMI connection between a server and a remote client.

When you run this example:

  • Registers a and a MBean in the local MBean server
  • Performs local operations on the MBeans
  • Creates an RMI connector server
  • Registers a and a MBean on the remote MBean server
  • Performs remote operations on both MBeans

The RMI connector example is contained in the directory work_dir.

  1. Open the work_dir directory.

    Inside this directory, you will find the following files:

  2. Open each of the files in a text editor.

Analyzing the Example Classes

The following sections analyze each of the classes used in the basic MBean example, and explain how they perform the operations described in the preceding section.

Due to its size, the class is shown in several code excerpts.

CODE EXAMPLE 3-1 MBean Example Class (Excerpt 1)

public class Server { public static void main(String[] args) { try { MBeanServer mbs = MBeanServerFactory.createMBeanServer(); waitForEnterPressed(); String domain = mbs.getDefaultDomain(); waitForEnterPressed(); String mbeanClassName = "SimpleStandard"; String mbeanObjectNameStr = domain + ":type=" + mbeanClassName + ",name=1"; ObjectName mbeanObjectName = createSimpleMBean(mbs, mbeanClassName, mbeanObjectNameStr); waitForEnterPressed(); printMBeanInfo(mbs, mbeanObjectName, mbeanClassName); waitForEnterPressed(); manageSimpleMBean(mbs, mbeanObjectName, mbeanClassName); waitForEnterPressed(); mbeanClassName = "SimpleDynamic"; mbeanObjectNameStr = domain + ":type=" + mbeanClassName + ",name=1"; mbeanObjectName = createSimpleMBean(mbs, mbeanClassName, mbeanObjectNameStr); waitForEnterPressed(); printMBeanInfo(mbs, mbeanObjectName, mbeanClassName); waitForEnterPressed(); manageSimpleMBean(mbs, mbeanObjectName, mbeanClassName); waitForEnterPressed(); [...]

Examining this class, you can see that the following occurs:

Firstly, the class creates a new MBean server called by calling the method of the class.

Then, the default domain in which the MBean server is registered is obtained with a call to the method of the interface. The domain is identified by the string .

The MBean class named is also identified by a variable, in this case the string . is the name of the Java class for the Java object of which this MBean is an instance. The object is examined in Section  "".

Another variable, the string , is defined as the combination of the domain, plus the following key=value pairs:

  • The , which in this case is the .
  • A , to differentiate this MBean from other MBeans of the same type that might be created subsequently. In this case the name number is .

The purpose of is to give the MBean a human-readable identifier.

A call to createSimpleMBean() creates and registers the SimpleStandard MBean in the local MBean server, with the given object name.

The operations , and are then performed on the MBean. Like , these methods are defined later in the code, and are shown in CODE EXAMPLE 3-4 and CODE EXAMPLE 3-5.

In code that is not shown here, a second MBean of the type is created and registered in the MBean server in exactly the same way as the MBean. As the name suggests, this MBean is an instance of the Java object, which is examined in Section  "".

CODE EXAMPLE 3-2 MBean Example Class (Excerpt 2)

[...] JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:9999/server"); JMXConnectorServer cs = JMXConnectorServerFactory.newJMXConnectorServer(url, null, mbs); cs.start(); waitForEnterPressed(); cs.stop(); [...]

In CODE EXAMPLE 3-2, an RMI connector server is created so that operations can be performed on the MBeans remotely. A call to the class creates a new service URL called , which serves as an address for the connector server. In this example, the service URL is given in JNDI form, rather than in encoded form (see the API documentation for the package for an explanation of JNDI form). This service URL defines the following:

  • The connector will use the default RMI transport, denoted by .
  • The RMI registry in which the RMI connector stub will be stored will be running on port on the local host, and the server address will be registered under the name . The port specified in the example is arbitrary; you can use any available port.

An RMI connector server named is created by calling the constructor , with the service URL , a environment map, and the MBean server as parameters. The connector server is launched by calling the method of , whereupon exports the RMI object to the RMI registry. The connection will remain open until the Enter key is pressed, as instructed by the simple method , that is defined later in the code.

CODE EXAMPLE 3-3 MBean Example Class (Excerpt 3)

[...] private static ObjectName createSimpleMBean(MBeanServer mbs, String mbeanClassName, String mbeanObjectNameStr) { echo("\n>>> Create the " + mbeanClassName + " MBean within the MBeanServer"); echo("ObjectName = " + mbeanObjectNameStr); try { ObjectName mbeanObjectName = ObjectName.getInstance(mbeanObjectNameStr); mbs.createMBean(mbeanClassName, mbeanObjectName); return mbeanObjectName; } catch (Exception e) { echo( "!!! Could not create the " + mbeanClassName + " MBean !!!"); e.printStackTrace(); echo("\nEXITING...\n"); System.exit(1); } return null; } [...]

CODE EXAMPLE 3-3 shows the definition of the method. In this method, the MBean instance with the object name is passed to the method of the interface to create a new object name for registering the MBean inside the MBean server. The resulting object name instance is named . A call to the method then instantiates an MBean defined by the combination of the Java object identified by and the MBean instance and registers this MBean in the MBean server .

CODE EXAMPLE 3-4 MBean Example Class (Excerpt 4)

[...] private static void printMBeanInfo(MBeanServer mbs, ObjectName mbeanObjectName, String mbeanClassName) { MBeanInfo info = null; try { info = mbs.getMBeanInfo(mbeanObjectName); } catch (Exception e) { echo( "!!! Could not get MBeanInfo object for " + mbeanClassName +" !!!"); e.printStackTrace(); return; } MBeanAttributeInfo[] attrInfo = info.getAttributes(); if (attrInfo.length > 0) { for (int i = 0; i < attrInfo.length; i++) { echo(" ** NAME: " + attrInfo[i].getName()); echo(" DESCR: " + attrInfo[i].getDescription()); echo(" TYPE: " + attrInfo[i].getType() + "READ: "+ attrInfo[i].isReadable() + "WRITE: "+ attrInfo[i].isWritable()); } } else echo(" ** No attributes **"); [...]

In CODE EXAMPLE 3-4 we see the definition of the method . The method calls the method to obtain details of the attributes and operations that are exposed by the MBean . defines the following methods, each of which is called in turn to obtain information about the MBean’s attributes:

  • , to obtain the attribute’s name.
  • , to obtain the human readable description of the attribute.
  • , to obtain the class name of the attribute.
  • , to determine whether or not the attribute is readable.
  • , to determine whether or not the attribute is writable.

In code that is not shown here, calls are made to obtain information about the MBean’s constructors, operations and notifications:

  • , to obtain information about the MBean’s Java class.
  • , to learn what operations the MBean performs, and what parameters it takes.
  • , to find out what notifications the MBean sends when its operations are performed.

CODE EXAMPLE 3-5 MBean Example Class (Excerpt 5)

[...] private static void manageSimpleMBean(MBeanServer mbs, ObjectName mbeanObjectName, String mbeanClassName) { try { printSimpleAttributes(mbs, mbeanObjectName); Attribute stateAttribute = new Attribute("State", "new state"); mbs.setAttribute(mbeanObjectName, stateAttribute); printSimpleAttributes(mbs, mbeanObjectName); echo("\n Invoking reset operation..."); mbs.invoke(mbeanObjectName, "reset", null, null); printSimpleAttributes(mbs, mbeanObjectName); } catch (Exception e) { e.printStackTrace(); } } private static void printSimpleAttributes( MBeanServer mbs, ObjectName mbeanObjectName) { try { String State = (String) mbs.getAttribute(mbeanObjectName, "State"); Integer NbChanges = (Integer) mbs.getAttribute(mbeanObjectName, "NbChanges"); } catch (Exception e) { echo( "!!! Could not read attributes !!!"); e.printStackTrace(); } } [...]

CODE EXAMPLE 3-5 shows a method for managing a simple MBean.

The method first of all calls the method that is also defined by . The method obtains an MBean attribute called from the MBean , as well as another MBean attribute called . Both of these attributes are defined in the class, shown in Section  "".

The method then defines an attribute called , which is an instance of the class. The attribute associates a value of with the existing attribute , defined by . A call to the method then sets the MBean’s state to the new state defined by .

Finally, a call to the method invokes the MBean’s operation. The operation is defined in the class.

The class is shown in CODE EXAMPLE 3-1.

CODE EXAMPLE 3-1 MBean Example Class

public interface SimpleStandardMBean { public String getState(); public void setState(String s); public int getNbChanges(); public void reset(); }

The class is a straightforward JMX specification management interface for the MBean . This interface exposes the four operations defined by for management through a JMX agent.

The class is shown in CODE EXAMPLE 3-1.

CODE EXAMPLE 3-1 MBean Example Class

public class SimpleStandard extends NotificationBroadcasterSupport implements SimpleStandardMBean { public String getState() { return state; } public void setState(String s) { state = s; nbChanges++; } public int getNbChanges() { return nbChanges; } public void reset() { AttributeChangeNotification acn = new AttributeChangeNotification(this, 0, 0, "NbChanges reset", "NbChanges", "Integer", new Integer(nbChanges), new Integer(0)); state = "initial state"; nbChanges = 0; nbResets++; sendNotification(acn); } public int getNbResets() { return nbResets; } public MBeanNotificationInfo[] getNotificationInfo() { return new MBeanNotificationInfo[] { new MBeanNotificationInfo( new String[] { AttributeChangeNotification.ATTRIBUTE_CHANGE }, AttributeChangeNotification.class.getName(), "This notification is emitted when the reset() method is called.") }; } private String state = "initial state"; private int nbChanges = 0; private int nbResets = 0; }

The class defines a straightforward JMX specification standard MBean.

The MBean exposes operations and attributes for management by implementing the corresponding interface, shown in Section  "".

The simple operations exposed by this MBean are as follows:

  • To count the number of times the state is updated
  • To reset the values of the state and the number of changes to their original value of zero
  • To send a notification whenever the reset operation is invoked

The notification emitted by the reset operation is an instance of the class , which collects information about the number of changes carried out on the attribute before calling reset. The content of the notification sent is defined by the instance.

The class is shown in CODE EXAMPLE 3-1.

CODE EXAMPLE 3-1 MBean Example Class

public class SimpleDynamic extends NotificationBroadcasterSupport implements DynamicMBean { public SimpleDynamic() { buildDynamicMBeanInfo(); } [...]

The dynamic MBean shows how to expose attributes and operations for management at runtime, by implementing the interface. It starts by defining a method, , for obtaining information for the MBean dynamically. The method builds the for the dynamic MBean.

The rest of the code of corresponds to the implementation of the interface. The attributes, operations and notifications exposed are identical to those exposed by the MBean.

The class is shown in CODE EXAMPLE 3-1.

CODE EXAMPLE 3-1 MBean Example Class

public class ClientListener implements NotificationListener { public void handleNotification(Notification notification, Object handback) { System.out.println("\nReceived notification: " + notification); } }

The class implements a straightforward JMX specification notification listener.

The method of the interface is called upon reception of a notification, and prints out a message to confirm that a notification has been received.

The class is shown in CODE EXAMPLE 3-1.

CODE EXAMPLE 3-1 MBean Example Class

public class Client { public static void main(String[] args) { try { // Create an RMI connector client // JMXServiceURL url = new JMXServiceURL( "service:jmx:rmi:///jndi/rmi://localhost:9999/server"); JMXConnector jmxc = JMXConnectorFactory.connect(url, null); ClientListener listener = new ClientListener(); MBeanServerConnection mbsc = jmxc.getMBeanServerConnection(); waitForEnterPressed(); // Get domains from MBeanServer // String domains[] = mbsc.getDomains(); for (int i = 0; i < domains.length; i++) { System.out.println("Domain[" + i + "] = " + domains[i]); } waitForEnterPressed(); String domain = mbsc.getDefaultDomain(); // Create SimpleStandard MBean ObjectName mbeanName = new ObjectName(domain +":type=SimpleStandard,name=2"); mbsc.createMBean("SimpleStandard", stdMBeanName, null, null); waitForEnterPressed(); // Create SimpleDynamic MBean ObjectName dynMBeanName = new ObjectName(domain +":type=SimpleDynamic,name=2"); echo("\nCreate SimpleDynamic MBean..."); mbsc.createMBean("SimpleDynamic", dynMBeanName, null, null); waitForEnterPressed(); // Get MBean count echo("\nMBean count = " + mbsc.getMBeanCount()); // Query MBean names echo("\nQuery MBeanServer MBeans:"); Set names = mbsc.queryNames(null, null); for (Iterator i = names.iterator(); i.hasNext(); ) { echo( "ObjectName = " + (ObjectName); } waitForEnterPressed(); mbsc.setAttribute(stdMBeanName, new Attribute("State", "changed state")); SimpleStandardMBean proxy = JMX.newMBeanProxy( mbsc, stdMBeanName, SimpleStandardMBean.class, true); echo("\nState = " + proxy.getState()); ClientListener listener = new ClientListener(); mbsc.addNotificationListener(stdMBeanName, listener, null, null); mbsc.invoke(stdMBeanName, "reset", null, null); mbsc.removeNotificationListener(stdMBeanName, listener); mbsc.unregisterMBean(stdMBeanName); [...] jmxc.close(); } catch (Exception e) { e.printStackTrace(); } } } [...]

The class creates an RMI connector client that is configured to connect to the RMI connector server created by .

As you can see, defines the same service URL as that defined by . This allows the connector client to retrieve the RMI connector server stub named from the RMI registry running on port of the local host, and to connect to the RMI connector server.

With the RMI registry thus identified, the connector client can be created. The connector client, , is an instance of the interface , created by the method of . The method is passed the parameters and a environment map when it is called.

The Client also creates an instance of , to listen for notifications, as shown in Section  "".

An instance of a JMX specification , named , is then created by calling the method of the instance .

The connector client is now connected to the MBean server created by , and can register MBeans and perform operations on them with the connection remaining completely transparent to both ends.

The client creates and registers the MBean and the SimpleDynamic MBean in the MBean server with a call to the method of , and performs the operations defined by and as if they were local JMX specification MBean operations.

MBean proxies allow you to access an MBean through a Java interface, allowing you to make calls on the proxy rather than having to write lengthy code to access a remote MBean. An MBean proxy for is created here by calling the method in the class, passing it the MBean’s , object name, the class name of the MBean interface and true, to signify that the proxy must behave as a . You can make proxies for MXBeans in exactly the same way as for standard MBeans, by simply calling instead of .

The code for the different operations performed on is not shown here, because the operations are the same as those performed on .

Finally, the client unregisters the MBean and closes the connection. The final is optional, as listeners registered by a remote client are removed when that client is closed.

Running the MBean Example

Having examined the example classes, you can now run the example. To run the example, follow the steps below, or see the file:

  1. Compile the Java classes.

    javac *.java

  2. Start an RMI registry on port of the local host.

    The RMI registry will be used by the to register the RMI connector stub.

    rmiregistry 9999 &

  3. Start the class.

    java -classpath . Server

    You will see confirmation of the creation of the MBean server and the creation of the MBean in the MBean server. You will then be prompted to press the Enter key to obtain information about, and then to perform operations on, the MBean.

    Once the operations on the have completed, the process will be repeated for the MBean.

    Once both the MBeans have been created and their operations performed, you see the creation of an RMI connector server, to allow operations to be performed on the MBeans from the remote .

  4. Start the class in another terminal window.

    java -classpath . Client

    You will see confirmation of the creation of the RMI connector client and of the connection with the connector server. You will also be informed of the domain name, and the creation and registration of and SimpleDynamic MBeans. The client will then perform operations on and SimpleDynamic MBeans, before unregistering them.

Contents | Previous | Next


Connectors jmx

JMX connector#

The JMX connector provides the ability to query Java Management Extensions (JMX) information from all nodes in a Trino cluster. This is very useful for monitoring or debugging. JMX provides information about the Java Virtual Machine and all of the software running inside it. Trino itself is heavily instrumented via JMX.

This connector can be configured so that chosen JMX information is periodically dumped and stored in memory for later access.


To configure the JMX connector, create a catalog properties file with the following contents:

To enable periodical dumps, define the following properties: jmx.dump-tables=java.lang:type=Runtime,trino.execution.scheduler:name=NodeScheduler jmx.dump-period=10s jmx.max-entries=86400

is a comma separated list of Managed Beans (MBean). It specifies which MBeans is sampled and stored in memory every . History has limited size of of entries. Both and have default values of and accordingly.

Commas in MBean names should be escaped in the following manner: jmx.dump-tables=trino.memory:name=general\\,type=memorypool,\ trino.memory:name=reserved\\,type=memorypool

Querying JMX#

The JMX connector provides two schemas.

The first one is that contains every MBean from every node in the Trino cluster. You can see all of the available MBeans by running :


MBean names map to non-standard table names, and must be quoted with double quotes when referencing them in a query. For example, the following query shows the JVM version of every node:

node | vmname | vmversion --------------------------------------+-----------------------------------+----------- ddc4df17-0b8e-4843-bb14-1b8af1a7451a | Java HotSpot(TM) 64-Bit Server VM | 24.60-b09 (1 row)

The following query shows the open and maximum file descriptor counts for each node:

openfiledescriptorcount | maxfiledescriptorcount -------------------------+------------------------ 329 | 10240 (1 row)

The wildcard character may be used with table names in the schema. This allows matching several MBean objects within a single query. The following query returns information from the different Trino memory pools on each node:

freebytes | node | object_name ------------+---------+---------------------------------------------------------- 214748364 | example | trino.memory:type=MemoryPool,name=reserved 1073741825 | example | trino.memory:type=MemoryPool,name=general 858993459 | example | trino.memory:type=MemoryPool,name=system (3 rows)

The schema contains the list of tables configured in the connector properties file. The tables have the same columns as those in the current schema, but with an additional timestamp column that stores the time at which the snapshot was taken:

timestamp | uptime -------------------------+-------- 2016-01-28 10:18:50.000 | 11420 2016-01-28 10:19:00.000 | 21422 2016-01-28 10:19:10.000 | 31412 (3 rows)
JMX: Much More Than Just Application Monitoring
  • Import the necessary classes

    import; import; import; import; import; import; import; import; import; import; import; import; import; import; import javax.naming.InitialContext; import org.jboss.jmx.interfaces.RemoteMBeanServer; import org.jboss.jmx.client.RMIClientConnectorImpl;
  • Instantiate a local MBeanServer (MBeanServerImpl)

    final MBeanServer lLocalServer = new MBeanServerImpl(); The local variable is made final because it is needed in the shutdown hook.
  • Load the logger MBean (is needed now because the Connector Factory is a standard JBoss MBean but maybe I should make it to a normal MBean to make it leaner).

    lLocalServer.createMBean( "org.jboss.logging.Logger", new ObjectName( "DefaultDomain :name=Logger" ) );
  • Load and start the ConnectorFactory MBean

    final ObjectInstance lFactoryInstance = lLocalServer.createMBean( "org.jboss.jmx.client.ConnectorFactoryService", new ObjectName( "DefaultDomain:name=ConnectorFactory" ) );
  • Look for the list of remote Connectors at a given JNDI server (lContext.getEnvironment() returns the actual properties from a given InitialContext).

    Hashtable lProperties = lContext.getEnvironment(); ConnectorFactoryImpl.JBossConnectorTester lTester = new ConnectorFactoryImpl.JBossConnectorTester(); Iterator lConnectors = (Iterator) lLocalServer.invoke( lFactoryInstance.getObjectName(), "getConnectors", new Object[] { lProperties, lTester }, new String[] { lProperties.getClass().getName(), lTester.getClass().getName() } );
  • Create a connection to the selected Connector (lConnectorName is an instance returned by the previous retrieved iterator). The ConnectorName contains the information about the server, protocol and the JNDI name of a found JMX Connector.

    RemoteMBeanServer lConnector = (RemoteMBeanServer) lLocalServer.invoke( lFactoryInstance.getObjectName(), "createConnection", new Object[] { lConnectorName }, new String[] { lConnectorName.getClass().getName() } );
  • Use the new Connector MBean on the local MBeanServer to get and set the attributes and perform operation on the chosen MBeans on the remote MBeanServer.

    Iterator i = pConnector.queryMBeans( null, null).iterator(); while( i.hasNext() ) { MBeanInfo info = pConnector.getMBeanInfo( ( (ObjectInstance) ); MBeanAttributeInfo[] aInfos = info.getAttributes(); ... MBeanOperationInfo[] oInfos = info.getOperations(); }
  • Register a Notification Listener on a remote MBean and wait for notification events sent from the remote MBean. The NotSerializableHandback is a helper class to be a serializable proxy for a Handback which maybe is not serializable.

    Iterator i = pConnector.queryMBeans( null, nullitemizedlist).iterator(); int j = 0; while( i.hasNext() ) { ObjectInstance lBean = (ObjectInstance); try { pConnector.addNotificationListener( lBean.getObjectName(), (NotificationListener) new Listener(), (NotificationFilter) null, new NotSerializableHandback( lBean.getObjectName() + "" + j++ ) ); ... But when you terminate the connector you have to remove the connection by using the Connector Factory to remove all the Notification Listener from the remote MBeanServer. lLocalServer.invoke( lFactoryInstance.getObjectName(), "removeConnection", new Object[] { lConnectorName }, new String[] { lConnectorName.getClass().getName() } );
  • Sours:

    Now discussing:

    Java Management Extensions

    Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices (such as printers) and service-oriented networks. Those resources are represented by objects called MBeans (for Managed Bean). In the API, classes can be dynamically loaded and instantiated. Managing and monitoring applications can be designed and developed using the Java Dynamic Management Kit.[1]

    JSR 003[2] of the Java Community Process defined JMX 1.0, 1.1 and 1.2. JMX 2.0 was being developed under JSR 255, but this JSR was subsequently withdrawn.[3] The JMX Remote API 1.0 for remote management and monitoring is specified by JSR 160.[4] An extension of the JMX Remote API for Web Services was being developed under JSR 262.[5]

    Adopted early on by the J2EE community, JMX has been a part of J2SE since version 5.0. "JMX" is a trademark of Oracle Corporation.


    JMX uses a three-level architecture:

    1. The Probe level - also called the Instrumentation level - contains the probes (called MBeans) instrumenting the resources
    2. The Agent level, or MBeanServer - the core of JMX. It acts as an intermediary between the MBean and the applications.
    3. The Remote Management level enables remote applications to access the MBeanServer through connectors and adaptors. A connector provides full remote access to the MBeanServer API using various communication (RMI, IIOP, JMS, WS-* …), while an adaptor adapts the API to another protocol (SNMP, …) or to Web-based GUI (HTML/HTTP, WML/HTTP, …).

    Applications can be generic consoles (such as JConsole[6] and MC4J[7]) or domain-specific (monitoring) applications. External applications can interact with the MBeans through the use of JMX connectors and protocol adapters. Connectors serve to connect an agent with a remote JMX-enabled management application. This form of communication involves a connector in the JMX agent and a connector client in the management application.

    Protocol adapters provide a management view of the JMX agent through a given protocol. Management applications that connect to a protocol adapter are usually specific to the given protocol.

    Managed beans[edit]

    A managed bean - sometimes simply referred to as an MBean - is a type of JavaBean, created with dependency injection. Managed Beans are particularly used in the Java Management Extensions technology - but with Java EE 6 the specification provides for a more detailed meaning of a managed bean.

    The MBean represents a resource running in the Java virtual machine, such as an application or a Java EE technical service (transactional monitor, JDBC driver, etc.). They can be used for collecting statistics on concerns like performance, resources usage, or problems (pull); for getting and setting application configurations or properties (push/pull); and notifying events like faults or state changes (push).

    Java EE 6 provides that a managed bean is a bean that is implemented by a Java class, which is called its bean class. A top-level Java class is a managed bean if it is defined to be a managed bean by any other Java EE technology specification (for example, the JavaServer Faces technology specification), or if it meets all of the following conditions:

    1. It is not a non-static inner class.
    2. It is a concrete class, or is annotated .
    3. It is not annotated with an EJB component-defining annotation or declared as an EJB bean class in .

    No special declaration, such as an annotation, is required to define a managed bean.

    An MBean can notify the MBeanServer of its internal changes (for the attributes) by implementing the . The application interested in the MBean's changes registers a listener () to the MBeanServer. Note that JMX does not guarantee that the listeners will receive all notifications.[8]


    There are two basic types of MBean:

    • Standard MBeans implement a business interface containing setters and getters for the attributes and the operations (i.e., methods).
    • Dynamic MBeans implement the interface that provides a way to list the attributes and operations, and to get and set the attribute values.

    Additional types are Open MBeans, Model MBeans and Monitor MBeans. Open MBeans are dynamic MBeans that rely on the basic data types. They are self-explanatory and more user-friendly. Model MBeans are dynamic MBeans that can be configured during runtime. A generic MBean class is also provided for dynamically configuring the resources during program runtime.

    An MXBean (Platform MBean) is a special type of MBean that reifiesJava Virtual Machine subsystems such as garbage collection, JIT compilation, memory pools, multi-threading, etc.

    An MLet (Management applet) is a utility MBean to load, instantiate and register MBeans in a MBeanServer from an XML description. The format of the XML descriptor is:[9]

    <MLET CODE = ''class'' | OBJECT = ''serfile'' ARCHIVE = ''archiveList'' [CODEBASE = ''codebaseURL''] [NAME = ''objectName''] [VERSION = ''version''] > [arglist] </MLET>


    JMX is supported at various levels by different vendors:

    • JMX is supported by Java application servers such as OpenCloud Rhino Application Server [1], JBoss, JOnAS, WebSphere Application Server, WebLogic, SAP NetWeaver Application Server, Oracle Application Server 10g and Sun Java System Application Server.
    • JMX is supported by the UnboundID Directory Server, Directory Proxy Server, and Synchronization Server.[10]
    • Systems management tools that support the protocol include Empirix OneSight, GroundWork Monitor, Hyperic, HP OpenView, IBM Director, ITRS Geneos, Nimsoft NMS, OpenNMS,[11]Zabbix, Zenoss Core , and Zyrion, SolarWinds, Uptime Infrastructure Monitor, and LogicMonitor.[12]
    • JMX is also supported by servlet containers such as Apache Tomcat.[13] & Jetty (web server)
    • MX4J[2] is Open Source JMX for Enterprise Computing.
    • jManage[3] is an open source enterprise-grade JMX Console with Web and command-line interfaces.
    • MC4J[4] is an open source visual console for connecting to servers supporting JMX
    • snmpAdaptor4j[5] is an open source providing a simple access to MBeans via the SNMP protocol.
    • jvmtop is a lightweight open source JMX monitoring tool for the command-line
    • Prometheus can ingest JMX data via the JMX exporter[14] which exposes metrics in Prometheus format.

    See also[edit]


    Further reading[edit]



    • Benjamin G Sullins, Mark B Whipple : JMX in Action: You will also get your first JMX application up and running, Manning Publications Co. 2002, ISBN 1-930110-56-1
    • J. Steven Perry: Java Management Extensions, O'Reilly, ISBN 0-596-00245-9
    • Jeff Hanson: Connecting JMX Clients and Servers: Understanding the Java Management Extensions, APress L. P., ISBN 1-59059-101-1
    • Marc Fleury, Juha Lindfors: JMX: Managing J2EE with Java Management Extensions, Sams Publishing, ISBN 0-672-32288-9

    External links[edit]


    414 415 416 417 418