Monitoring JMS resources with WildFly

In this quick tutorial we will show how to monitor the critical metrics of JMS subsystem of standalone and domain WildFly servers.

Firstly, start WildFly using a distribution that includes the messaging subsystem (e.g.): -c standalone-full.xml

You can inspect JMS metrics both using the CLI and the Web admin interface. Besides, you can use any JMX-compliant tool to inspect the metrics. Let’s see each use case in detail.

Using the CLI to monitor JMS Resources

If you want to monitor a JMS destination using the CLI, you can use the read-resource command on the selected destination (for example the testQueue):

    "outcome" => "success",
    "result" => {
        "consumer-count" => 0,
        "dead-letter-address" => "jms.queue.DLQ",
        "delivering-count" => 0,
        "durable" => true,
        "entries" => ["jms/testQueue"],
        "expiry-address" => "jms.queue.ExpiryQueue",
        "legacy-entries" => undefined,
        "message-count" => 2L,
        "messages-added" => 2L,
        "paused" => false,
        "queue-address" => "jms.queue.TestQueue",
        "scheduled-count" => 0L,
        "selector" => undefined,
        "temporary" => false

And this is a list of the key metrics:

  • consumer-count: The number of consumers which are active for this destination
  • message-count: The number of messages currently waiting to be consumed in this destination.
  • delivering-count: The number of messages that this destination is currently delivering to its consumers.
  • scheduled-count: The number of scheduled messages in this destination.
  • messages-added: The number of messages added to this destination since creation.

Message Count vs Message Added

Message Count refers to the number of messages currently in this queue. On the other hand, messages-added is total number of messages added to this queue since its creation.

If you are running in domain mode, you have to specify the host and server before the subsystem:


Handy Trick: how to read a metric using the Bash shell

If you are running a linux shell (or en emulator for Windows) you can take advantage of non-interactive features of CLI to read a single attribute which can be stored into a shell variable. Create a file named for example metric.cli which contains the connect command and a read-attribute of a metric (e.g. the consumer-count)


Next, execute this cli in non-interactive mode, capturing with awk the result:

consumers=$( –-file=metric.cli | awk '$1=="\"result\"" {print $3}')

if you try to echo the consumers variable, it will contain the number of consumers for a JMS Destinations

$ echo "$consumers"


Using the Web admin console

You can use as well the Web admin console which exposes the same metrics by navigating into the Runtime upper tab and selecting the JMS Destinations in the left panel:

monitor jms wildflyjms moniotor wildfly

Using JMX to monitor the Broker

Finally, you can use any JMX Resource, such as JConsole, to monitor JMS Metrics. As an example, start JConsole and connect to WildFly PID.

Then, head to the messaging-activemq > Server > Destination. You will find the current metrics under the Attributes of the Destination.

Example: the following screenshot show the metrics for the Destination MyQueue which is available under the default Artemis Server:

monitor wildfly jms metrics

To learn more about monitoring WildFly using JConsole, we recommend checking this article: Using JConsole to monitor a remote WildFly server