|Skip Navigation Links|
|Exit Print View|
|Oracle GlassFish Server Message Queue 4.5 Administration Guide|
The JMX API allows Java client applications to monitor and manage broker resources by programmatically accessing JMX MBeans (managed beans) that represent broker resources. As explained in the JMX-Based Administration in Oracle GlassFish Server Message Queue 4.5 Technical Overview, the broker implements MBeans associated with individual broker resources, such as connection services, connections, destinations, and so forth, as well as with whole categories of resources, such as the set of all destinations on a broker. There are separate configuration MBeans and monitor MBeans for setting a resource’s configuration properties and monitoring its runtime state.
In the JMX implementation used by Message Queue, JMX client applications access MBeans using remote method invocation (RMI) protocols provided by JDK 1.5 (and later).
When a broker is started, it automatically creates MBeans that correspond to broker resources and places them in an MBean server (a container for MBeans). JMX client applications access the MBean server by means of an JMX RMI connector (heretofore called a JMX connector), which is used to obtain an MBean server connection, which, in turn, provides access to individual MBeans.
The broker also creates and configures two default JMX connectors, jmxrmi and ssljmxrmi. These connectors are similar to the broker connection services used to provide connections to the broker from JMS clients. By default, only the jmxrmi connector is activated at broker startup. The ssljmxrmi connector, which is configured to use SSL encryption, can be activated using the imq.jmx.connector.activelist broker property (see To Activate the SSL-Based JMX connector ).
JMX client applications programmatically access JMX MBeans by first obtaining an MBean server connection from the jmxrmi or ssljmxrmi connector. The connector itself is accessed by using a proxy object (or stub) that is obtained from the broker by the JMX client runtime, as shown in the following figure. Encapsulated in the connector stub is the port at which the connector resides, which is dynamically assigned each time a broker is started, and other connection properties.
Figure D-1 Basic JMX Infrastructure
JMX client applications obtain a JMX connector stub using an address called the JMX service URL. The value and format of the JMX service URL depends on how the broker's JMX support is configured:
Static JMX service URL. The JMX service URL specifies the location of the JMX connector stub in an RMI registry. When the broker is started, it creates the JMX connector stub and places it in the specified location in the RMI registry. This location is fixed across broker startups.
Dynamic JMX service URL.The JMX service URL contains the JMX connector stub as a serialized object. This URL is dynamically created each time the broker is started.
A JMX service URL has the following form:
where rmi://brokerHost[:connectorPort] specifies the host (and optionally a port) used by the JMX connector. By default the port is assigned dynamically on broker startup, but can be set to a fixed value for JMX connections through a firewall.
The urlpath portion of the JMX service URL depends on whether the JMX service URL is static (see Static JMX Service URL: Using an RMI Registry) or dynamic (see Dynamic JMX Service URL: Not Using an RMI Registry). In either case, you can determine the value of the JMX service URL by using the imqcmd list jmx subcommand (see the examples in RMI Registry Configuration).
By default, the broker does not use an RMI registry, and the JMX runtime obtains a JMX connector stub by extracting it from a dynamic JMX service URL. However, if the broker is configured to use an RMI registry, then JMX runtime uses a static JMX service URL to perform a JNDI lookup of the JMX connector stub in the RMI registry. This approach, illustrated in the following figure, has the advantage of providing a fixed location at which the connector stub resides, one that does not change across broker startups.
Figure D-2 Obtaining a Connector Stub from an RMI Registry
Message Queue also provides, as a convenience, an AdminConnectionFactory class that hides the details of the JMX Service URL and JMX connector stub. The Admin Connection Factory uses the Message Queue Port Mapper service to get the relevant JMX Service URL (regardless of the form being used) and thereby obtain a JMX connector stub. JMX applications that use the Admin Connection Factory only need to know the broker's host and Port Mapper port. The scheme is shown in the following figure.
Figure D-3 Obtaining a Connector Stub from an Admin Connection Factory