MQTT 3.1.1 support in JBoss A-MQ 6.1, Apache ActiveMQ 5.10-SNAPSHOT and Apache Camel 2.13.0

I had the good fortune of recently attending the MQTT Interoperability Test Day during the recent EclipseCon in Burlingame, California on March 17th 2014. The event was held by the Eclipse Foundation and the Eclipse IoT Working Group. It’s aim was to prove spec maturity of MQTT 3.1.1 by demonstrating industry adoption and interoperability among products that support them, and to potentially iron out any issues in the spec that might show up through the exercise. MQTT is a key protocol for the rapidly growing IoT approach. If you haven’t heard of MQTT before you should definitely check out At the event I was representing Red Hat Inc. and its JBoss A-MQ 6.1 (Early Access build 367) product, Apache ActiveMQ 5.10-SNAPSHOT, and Apache Camel 2.13.0. As part of the exercise Ian Craggs from the Eclipse Paho team had built a very useful mock client and server to check compliance with the draft MQTT 3.1.1 spec. That Python kit proved very valuable to the Fuse team and I in helping find and address several issues in Apache ActiveMQ’s MQTT protocol implementation. More information on Ian’s test kit can be found at As a result of all the testing and fixes, the MQTT implementation in ActiveMQ has improved by leaps and bounds. I also wrote test Java clients and server using the Fuse mqtt-client library, Apache Camel and the Apache ActiveMQ broker in JBoss A-MQ 6.1. The test client I wrote mirrors tests executed by Ian’s Python client. It verified compliance with several key improvements in MQTT 3.1.1 listed below:

  1. Basic publish subscribe
  2. Retained messages
  3. Offline message queueing
  4. Will messages for client disconnects
  5. Overlapping subscriptions with MQTT wildcards
  6. Connection keep alive
  7. Redelivery of messages on reconnect
  8. Zero length client id (optional)
  9. Dollar topics (optional)
  10. Subscription failure (optional)

The improvements in ActiveMQ MQTT support were demonstrated when both the client and server passed all the above tests with flying colors when tested against the Python compliance test client and server as well as several other MQTT products tested for interoperability during the Interop Test Day. Since I implemented several fixes in the MQTT transport for ActiveMQ as well as some critical fixes in the Broker for supporting MQTT topics and wildcards, I can state that there is only one spec requirement (MQTT-3.1.4–2) that isn’t supported at the moment.

That requirement is questionable since it mandates that MQTT Brokers MUST disconnect an existing client connection when another connection sends a CONNECT packet with the same client id. This will cause issues in client libraries such as Fuse mqtt-client, which automatically reconnect when disconnected from the Broker. So ActiveMQ chooses to reject the new connection instead.

The code for my Java JBoss A-MQ test clients and server configuration can be found at The instructions for running them are simple and found in the files.

All in all it was a very fruitful event, personally for me since I put in a lot of work to get all the MQTT issues fixed in Apache ActiveMQ, and for Red Hat to be able to now proudly say that we support MQTT 3.1.1 spec in a soon to be GA product JBoss Fuse A-MQ 6.1.

Of course this wouldn’t have been possible without the hard work by Ian Skerret from the Eclipse Foundation in organizing the Interop Test Day, and all the help and support I received from my colleagues in Fuse engineering team at Red Hat. I hope you take the time to check out the Java test clients and Broker and have lots of fun using MQTT in your applications.

Originally published at on April 3, 2014.

Like what you read? Give Dhiraj Bokde a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.