| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
| Skip Navigation Links | |
| Exit Print View | |
|
|
Oracle GlassFish Server Message Queue 4.5 Administration Guide |
Part I Introduction to Message Queue Administration
1. Administrative Tasks and Tools
3. Starting Brokers and Clients
6. Configuring and Managing Connection Services
8. Configuring Persistence Services
9. Configuring and Managing Security Services
10. Configuring and Managing Broker Clusters
11. Managing Administered Objects
12. Configuring and Managing Bridge Services
13. Monitoring Broker Operations
14. Analyzing and Tuning a Message Service
17. Broker Properties Reference
18. Physical Destination Property Reference
19. Administered Object Attribute Reference
20. JMS Resource Adapter Property Reference
21. Metrics Information Reference
22. JES Monitoring Framework Reference
A. Distribution-Specific Locations of Message Queue Data
B. Stability of Message Queue Interfaces
Static JMX Service URL: Using an RMI Registry
Dynamic JMX Service URL: Not Using an RMI Registry
JMX Client Side SSL Configuration
JMX Connections Through a Firewall
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:
service:jmx:rmi://brokerHost[:connectorPort]urlpath
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
For programmatic details, see Obtaining a JMX Connector from an Admin Connection Factory in Oracle GlassFish Server Message Queue 4.5 Developer’s Guide for JMX Clients
|