Skip to main content

Integration & IT Modernization

Configuring MQTT on IBM MQ

Where to Begin After a Marketo Audit

September 27, 2019.

Let’s talk about setting up MQTT in MQ v9.1.x. Remember that images are clickable for a sharper picture.


Full name of MQTT is IBM MQ Telemetry v3 protocol, and it’s used for lightweight pub/sub between small footprint devices over unreliable networks. It uses TCP/IP as the backbone. Three Qualities of Service (QoS) are supported: “fire and forget”, “at least once”, and “exactly once”.

I’ll provide two examples of use cases for MQTT:

  1. A gas pipeline somewhere deep in Alaska delivering natural gas from far north to U.S. mainland. It has thousands of sensors that constantly send their data over to an MQTT server. Data includes temperature, particle density (for leak detection), pressure, etc. A queue manager receives these messages at regular intervals and distributes them to subscribers. Missing one set of messages is not critical, another one will arrive after a time interval has passed. QoS in this case can be set to “fire and forget” or “at least once”.
  2. Bedside medical devices next to hospital beds send similar data. Blood pressure, pulse, and other vital signs are sent at regular intervals (much shorter intervals if a patient is in intensive care). This time missing one set of vitals could be an indication of an emergency, and the networks in hospitals are much more reliable than in the wilderness. Thus, QoS in this case could be set to “exactly once”.

Technical Steps

How do we set this up?

Create a queue manager

First, we create a queue manager that will handle only MQTT traffic. The reasons for this are provided below. It’s a regular queue manager with all of your standard settings (including TLS as described in one of my previous posts).

Setup JAAS

Second, if you’re using LDAP authentication, you will need to modify a Java Authentication and Authorization Service (JAAS) configuration file for MQTT.

For shared file systems (multi-instance queue managers), it will be here:


For stand-alone queue managers the file will be here:


Modify the entry inside to look like the next example. You can find this information in your LDAP connection authentication object on the queue manager:

userProvider=”ldaps://,dc=unix,dc=domain,dc=com ldaps://,dc=unix,dc=domain,dc=com”

Define a service

Next, we create an MQTT service. The name has to be SYSTEM.MQXR.SERVICE. The rest of the parameters are standard and are provided by the MQ installation:


Then we start the service:


At this point I found it necessary to restart the MQ Explorer (MQE) to pick up the service, and allow browsing of the Telemetry folder.

Define a channel

Next step is to define a channel. Note that you will need one port per channel. Also note that SSLCAUTH (NEVER) sets up one-way authentication. Set SSLCAUTH (REQUIRED) to enable two-way or mutual authentication:


Set default transmission queue

As the last step we need to change the default transmission queue of the queue manager to SYSTEM.MQTT.TRANSMIT.QUEUE:


After starting the service and the channel, you’re ready to use MQTT pub/sub.

MQTT Subscriptions

In order to transition to the next phase, we need a little bit of theory.

There are two ways for the MQTT subscriptions to work.

  1. Make SYSTEM.MQTT.TRANSMIT.QUEUE the default transmission queue on the queue manager.
  2. Create a queue manager alias named the same as the client id. The client id must also be the name of a remote queue manager. A queue manager alias is a remote queue definition that allows administrators to redirect messages.

MQTT setup example:


Approach two is tedious to setup and cumbersome to administer. You will need at least one queue manager alias for each work account that wants to use subscriptions. It could turn into a micro-management nightmare when hundreds of accounts are involved. There is one benefit in this approach: controlled access on who can subscribe.

Approach one is a much better option, but there is a reef we need to avoid. If a queue manager that is not part of a cluster puts a message onto a remote queue, the default action is to use the default transmission queue. In approach I. that queue will be defined as SYSTEM.MQTT.TRANSMIT.QUEUE. Now a scenario is possible when a remote queue is defined that doesn’t have a transmission queue defined, and the queue manager will use the default transmission queue. A message, not intended for MQTT, will be sent to MQTT subscribers. For this reason a dedicated queue manager is advisable for MQTT configurations.

Using MQ Explorer

In MQE you can see and administer the objects we created. Some screenshots.

MQTT channel:

MQTT service:

MQTT Utilities

There are two ways you can smoke-test your configuration.

An MQTT Client utility can be launched from MQE:

A browser can be directed to the channel’s hostname and port. For example, if your queue manager is running on and you created an MQTT channel on port 1884, then use URL:

You can use both utilities to create a topic, send a message and receive it over a subscription.

Have fun!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Igor Solomatin, Technical Architect

Graduated from San Francisco State University with a Bachelor of Science degree in Computer Science. Worked at IBM as a WebSphere Technical Specialist from 2005 to 2010. Proud to be a team member at Perficient since 2014!

More from this Author

Follow Us