JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients
search filter icon
search icon

Document Information


1.  Overview

2.  Using the Java API

3.  Message Queue Clients: Design and Features

4.  Using the Metrics Monitoring API

Monitoring Overview

Administrative Tasks

Implementation Summary

To Implement Message-Based Monitoring

Creating a Metrics-Monitoring Client

To Monitor Broker Metrics

Format of Metrics Messages

Broker Metrics

JVM Metrics

Destination-List Metrics

Destination Metrics

Metrics Monitoring Client Code Examples

A Broker Metrics Example

A Destination List Metrics Example

A Destination Metrics Example

5.  Working with SOAP Messages

6.  Embedding a Message Queue Broker in a Java Client

A.  Warning Messages and Client Error Codes


Monitoring Overview

Message Queue includes an internal client that is enabled by default to produce different types of metrics messages. Production is actually enabled when a client subscribes to a topic destination whose name matches one of the metrics message types. For example, if a client subscribes to the topic mq.metrics.jvm, the client receives information about JMV memory usage.

The metrics topic destinations (metric message types) are described in Table 4-1.

Table 4-1 Metrics Topic Destinations

Topic Destination Name
Type of Metrics Messages
Broker metrics: information on connections, message flow, and volume of messages in the broker.
Java Virtual Machine metrics: information on memory usage in the JVM.
A list of all destinations on the broker, and their types.
Destination metrics for a queue of the specified name. Metrics data includes number of consumers, message flow or volume, disk usage, and more. Specify the destination name for the dn variable.
Destination metrics for a topic of the specified name. Metrics data includes number of consumers, message flow or volume, disk usage, and more. Specify the destination name for the dn variable.

A metrics message that is produced to one of the destinations listed in Table 4-1 is a normal JMS message; its header and body are defined to hold the following information:

To receive metrics messages, the consuming client must be subscribed to the destination of interest. Otherwise, consuming a metrics message is exactly the same as consuming any JMS message. The message can be consumed synchronously or asynchronously, and then processed as needed by the client.

Message-based monitoring is concerned solely with obtaining metrics information. It does not include methods that you can call to work with physical destinations, configure or update the broker, or shutdown and restart the broker.

Administrative Tasks

By default the Message Queue metrics-message producing client is enabled to produce nonpersistent messages every sixty seconds. The messages are allowed to remain in their respective destinations for 5 minutes before being automatically deleted. To persist metrics messages, to change the interval at which they are produced, or to change their time-to-live interval, the administrator must set the following properties in the file: imq.metrics.topic.persist , imq.metrics.topic.interval, and imq.metrics.topic.timetolive .

In addition, the administrator might want to set access controls on the metrics destinations. This restricts access to sensitive metrics data and helps limit the impact of metrics subscriptions on overall performance. For more information about administrative tasks in enabling message-based monitoring and access control, see Using the Message-Based Monitoring API in Oracle GlassFish Server Message Queue 4.5 Administration Guide.

Implementation Summary

The following task list summarizes the steps required to implement message based monitoring:

To Implement Message-Based Monitoring

  1. The developer designs and writes a client that subscribes to one or more metrics destinations.
  2. The administrator sets those metrics-related broker properties whose default values are not satisfactory.
  3. (Optional) The administrator sets entries in the file to restrict access to metrics information.
  4. The developer or the administrator starts the metrics monitoring client.

    When consumers subscribe to a metrics topic, the topic’s physical destination is automatically created. After the metrics topic has been created, the broker’s metrics message producer begins to send metrics messages to the appropriate destination.