Dec 07

Every now and then someone has a need/desire to collect and process performance and usage metrics of JMS destinations and the messaging system.  Knowing that there is a buildup of messages in a particular destination over time might indicate that a downstream component is failing or the downstream external system is not available. This, in turn, may enable operational staff in the enterprise to intervene before things get out of hand. In more sophisticated solutions, knowing that a buildup of messages occurs may enable the solution to automatically bring on line additional resources, perhaps by starting additional copies of appropriate components or starting additional machines which host consumers that will take up the load.

The Java Message Queue implementation (hereafter Java MQ) has monitoring metrics collection built in and provides a convenient way of programmatic access to these metrics.

Java CAPS 5.1, Java CAPS 6, GlassFish ESB (commercially supported subset of OpenESB) and OpenESB all provide support for the Java MQ as the messaging infrastructure so solutions can be built to take advantage of this functionality.

This Note presents example projects, built using Java CAPS 6 Classic components and an example built using the Java CAPS 6/GlassFish ESB JMS JCA Adapter, which receive and “process” Java MQ metrics. How you can take advantage of this capability in your enterprise solutions is up to you and your creativity.

3 Responses to “Java CAPS 6, GlassFish ESB, Java Message Queue 4.1, Obtaining and using Java MQ Monitoring Metrics”

  1. Rajan Jain says:


    Pardon my stupid quesion.

    We need to monitor a queue and if we add a consumer to a queue to collect metrics data, it will consume the msg itself, I would be forced to combine business functionality with metrics gathering.

    Can we write a separate program, which will wake up after every 5 mins and connect to a queue, get the metrics and then disconnect.

    PS: I already know how to schedule a job, my question is how would a program connect to a queue, so that it doesnt consume the message, but just gather’s metrics of the destiation (queue)


  2. Michael Czapski says:

    Hello, Rajan.

    To collect metrics about a Queue qXX your metrics consumer does not connects to the JMS Queue which to monitor, but rather it connects to a _JMS Topic_ with the name of "mq.metrics.destination.queue.qXX".



  3. Michael Czapski says:

    By default the Java MQ broker will send monitoring metrics messages to consumers every 60 seconds. This default can be changed globally. See reference:, which says:

    "By default the Message Queue metrics-message producing client is enabled to produce non-persistent 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, imq.metrics.topic.timetolive. "

Leave a Reply

preload preload preload