The simplest JMS request/reply I could come up with for ActiveMQ and JBoss A-MQ

In case you find yourself needing to set up some JMS request/reply code, I hope this helps (the whole example, including writing this post took less than one hour for me). It’s the simplest example I could come up with for ActiveMQ (and JBoss A-MQ, of course). By simple  I mean it focuses as much on the simple task as possible without adding any other frameworks, magic tricks, or whatever — just pure JMS API.

First, create the request message

Here’s the code:

You’ll notice that, compared to a simple send method, the request/reply is a little more complicated in the following ways: you need to create a temporary reply queue (goes in the JMSReplyTo header), a correlation ID (JMSCorrelationID), and then start listening for a reply message.

When you run this, you should see the following if you log into JBoss A-MQ and browse the messages (ActiveMQ lets you do something similar through its web interface too):


Notice the JMSCorrelationID and the JMSReplyTo headers are set.

Next, subscribe and reply

The code to respond to the message mirrors the sender’s code:

Assuming that the sender code is running, if you run the code above, you should then see this in your IDE or console:


The full code is available on Github. Good luck out there, and let me know how this demo goes for you.

Demo: JBoss A-MQ, Websockets/HTML5, and Gordon Gecko

Back in early 2013, Eric Schabell, a Red Hat JBoss evangelist, created a cool JBoss A-MQ demo based on HTML5 websockets. You can see the YouTube demo here and access the JBoss Github repo for the demo here.

I wanted to work through it myself; only, it didn’t work for me out of the box. I fixed it and submitted a pull request, but while we’re waiting for the JBoss folks to accept the PR (’cause you know they should!), you can use the changes on my fork. Plus, I’ll help you out if you hit issues (I’m a consultant, you know…). But let’s walk through the demo for fun and clarification.

Running the demo

The README in the demo repo has all the nitty gritty details you need, but you might want an overview first since it’s a little more involved than just firing up a web application.

  1. Download a recent copy of JBoss A-MQ 6.1 from the JBoss Developer site and copy it to the “installs” directory — even if you already have A-MQ installed.
  2. Run the script to build all the artifacts you need and to provision the A-MQ installation correctly.
  3. Start the “feeder” standalone client, which will start putting stock price (and news) messages on JMS topics.
  4. Install the Websocket OSGI features as well as the demonstration web app.

What it looks like when you stay on the demonstration’s happy path

You’ll start the Karaf command-line client (from target/{amq_version}/bin).


After installing the websocket application, you’ll see installed near the end of the osgi:list:


Next, you’ll start your feeder application from the support directory (support/ You should start seeing messages flowing into the A-MQ topic such as the following:


Finally, you’ll load up a web browser and start seeing messages flowing through websockets to update web stock prices dynamically:


What the demonstration does under the hood

The demonstration shows really well, but you’re probably interested in what’s happening under the hood and how it may (or may not) apply to the work you actually do.

How the demonstration initialization script provisions the A-MQ server

First of all, you might bristle a little at the init script. Let’s talk about what it does because it’s not as black box or magical as it might appear.

  1. It unpacks the JBoss A-MQ installation you downloaded and puts it in the target directory.
  2. It copies over some configuration files. These files mostly just add security accounts so the feeder and client UI can interact.
  3. It runs Maven builds on the feeder and web UI clients so you can (a) run the feeder script and (b) install the web application and websocket features.

The Java code for the message producer and consumers

There are two Java applications that ship with the demo. The “feeder” application puts fake stock and news updates on two JMS topics: stockQueueTopic and newsTopic. The following is just a snippet from FeedThread on how the feeder applcation accesses A-MQ and the topics I just mentioned:

The Websocket-based client code uses the STOMP protocol through Jeff Mesnil’s stomp.js client code. One you login, it starts sending websocket frames to populate the screen I showed you above.


Cool, huh? You might bump into issues out there, so let me know what we can do to improve it.

Fun and profit in your first few hours with JBoss A-MQ

As part of my pitch to the Virtual JBoss User Group, I’ve been trying to think of the best way to explain how to get started with Red Hat JBoss A-MQ(A-MQ) and how to compare / contrast it with Apache ActiveMQ. While they share the same lineage, the user experience is very different.

So I thought I’d give you a few notes on how to play around with it and to visually work with the administrative interface. To follow along, you’ll need to download both Apache ActiveMQ and JBoss A-MQ because I’m going to rely on the example code bundled with ActiveMQ.

Discovering the A-MQ web interface

After starting A-MQ from the command line, navigate to the hawtio-based interface by loading http://localhost:8181, which is different from ActiveMQ’s default port. Login with username admin, password admin, which are the defaults, and you’ll see something like this:


Watching messages in the queue

Let’s start by sending and receiving some messages. By default, A-MQ runs only the OpenWire protocol. Since ActiveMQ ships example code with multiple protocols, let’s focus by opening ActiveMQ’s example code for OpenWire from this directory:

This code produces and consumes TextMessage messages through two classes: Producer and Listener. After Producer sends 10,000 messages, it sends a message with a body of “SHUTDOWN” which causes Consumer to shutdown and stop listening. To run this with A-MQ, you’ll need to change the hard coded user and password  to “admin” / “admin.”

To make the admin console come to life, we need to slow down the Listener and Producer before we run them because otherwise everything will happen so fast that you won’t be able to observe what’s happening on the hawtio interface. There are many ways to do this, but I just added some sleep statements in the code (about line 48 in Listener class):

Now let’s watch the messages. Start the Producer class and then the Consumer class (they each run independently). The hawtio interface should update pretty fast, and you’ll see this by default (I renamed my queue in the code to “test2,” which is why your queue name will probably say “example”):

a-mq active

Interesting information, but I really just want to know more about the messages actually flowing through the queue at this point. If you click on the “Edit Chart” button near the top, you can the information. I just picked “Queue Size” because I just want to know how many messages get queued up:


Now let’s run it again, but this time start the Producer first and then wait 20-30 seconds before starting the Consumer. You should see something like this:


Your Queue size should grow, stabilize for a while, and then start to shrink. Kind of cool. You might actually see a visual graph too — I think mine didn’t show up in the screenshot because I compressed the view.

Let’s send a message from A-MQ’s hawtio interface to your Java code

For me, I started a git repo on the ApacheMQ examples — you may want to do the same before you start the following example. Since we’re going to send a TextMessage from the hawtio web interface to our Java code, let’s add a little code to the while loop in the Listener class as follows:

As you can see, we’re going to listen for a TextMessage that says “HELLO.” Set a break point on the System.out if you want or just run the Listener class. The Listener is waiting for a message that says “HELLO”. Don’t start the Producer class this time.

Instead, return to the hawtio interface. Click on your queue, which is probably named “example” but could be whatever you named your queue from above (I named mine test2). Then click on “operations” in the context menu as follows:


Now, scroll down a bit and create a TextMessage by clicking on the ambiguously named option “Send text message(java.lang.string, java.lang.string, java.lang.string)” and enter the following:


If everything work correctly (and it always does on my machine, btw), then you should see something like the following:


Good luck out there, and let me know how your mileage varies…