3

I have many instances of my client application. These clients send requests to a server application via messaging and receive a reply. Normally the reply would be sent using a temporary queue.

Unfortunately I have to use the Stomp protocol which has no concept of temporary queues or topics. (Although the message broker has)

What's the best way to ensure only the original requestor receives the reply? Are there any best-practices for this unfortunate situation?

skaffman
  • 398,947
  • 96
  • 818
  • 769
Daniel Rikowski
  • 71,375
  • 57
  • 251
  • 329
  • I imagine this is going to depend heavily on the technology you're using (and which you haven't mentioned). – skaffman Jan 31 '11 at 10:56
  • I want a solution compatible with JMS and agnostic to any concrete messaging implementation. I could have mentioned I'm using ActiveMQ, but I don't want to make my application depend on something only possible with ActiveMQ. – Daniel Rikowski Jan 31 '11 at 12:09
  • @DR: The stomp protocol pretty much locks you into ActiveMQ anyway, doesn't it? None of the "real" enterprise JMS providers use it. – skaffman Jan 31 '11 at 15:11
  • With WebSphere MQ this is not an issue. You just configure your reply-to JNDI object to point to a model queue. The app doesn't know the difference between a temporary queue and a pre-defined queue. All it knows is the JNDI object name. I'm not familiar with other vendor's implementations but don't most of them have something similar? – T.Rob Jan 31 '11 at 15:18
  • @T.Rob: The question is more: What's the best way to guarantee that only the requesting client receives the response and not any other. – Daniel Rikowski Jan 31 '11 at 19:30
  • @skaffman: True, only a handful brokers seem to support it (http://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol) and I'm not happy with it either, but i didn't found any better messaging protocol which can be easily used with Ruby. There are some (OpenWire, AMQP, ...) but the client implementions look somewhat hacky. Perhaps I open another question for that issue... – Daniel Rikowski Jan 31 '11 at 19:37
  • @DR, OK I was struggling with the premise and even found a few examples of using Stomp with temp queues. However if I focus on "what's the best way to guarantee that only the requesting client receives the response and not any other?" then the answer is a well known pattern. More in the responses below. – T.Rob Jan 31 '11 at 20:02
  • @T.Rob: Your are right, Stomp *does* support temporary queues and topics. In fact the docs for Stomp and ActiveMQ are a mess and seriously outdated at some places. – Daniel Rikowski Feb 01 '11 at 11:12
  • Update: RabbitMQ, HornetQ, and many others now support STOMP, too. – Paul Legato Mar 11 '13 at 23:27

2 Answers2

4

The customary solution when several requestors listen for replies on the same queue is to use correlation IDs to select messages. On the client side it looks like this:

  1. Place a message on the request queue and commit.
  2. Retrieve the JMSMessageID from the outbound message (the value is determined by the broker and updates the message object as a result of the send).
  3. Receive a message from the reply queue specifying the JMSMessageID from the outbound message as the correlation ID in the selector.
  4. Process and commit.

On the server side it looks like this:

  1. Receive a message under syncpoint.
  2. Process the request and prepare the response.
  3. Set the JMSCorrelationID on the response to the value of JMSMessageID from the request.
  4. Send the message.
  5. Commit.

The consumer would set the selector something like this: activemq.selector:JMSCorrelationID=.

Since the broker creates a message ID that is supposed to be globally unique, the pattern of using it as the correlation ID prevents collisions that are possible when each requestor is allowed to specify it's own value.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
2

The best way to implement this pattern with JMS (that I've found, anyway) is to create a pre-configured topic for the response messages, and use correlation selectors on the response message so that the client can get the correct one.

In more detail, this means setting a random ID on the request message (using setJMSCorrelationID()), and putting that message on the request Queue. The consumer of that request message processes it, creates the response message, sets the same correlation ID on the response message, and puts it on the response Topic. The client, meanwhile, is listening on the response topic with a selector expression which specifies the correlation ID that it's expecting.

The danger is that the response message is sent before the client can get around to listening for it, although that's probably unlikely. You can try using a pre-configured Queue for the responses rather than a topic, but I've found that topics tend to work more reliably (my JMS provider of choice is HornetQ - your mileage may vary).

All this is tell me that JMS is a very poor fit for the request/response model. The API just doesn't support it properly. This is hardly surprising, since that was never a use-case for JMS.

Something like a compute grid (Terracotta, Gigaspaces, Infinispan, etc) would likely yield better results, but that's not really an option for you.

skaffman
  • 398,947
  • 96
  • 818
  • 769
  • Although that race condition is unlikely, is it generally acceptable for your applications? I work mostly in the financial sector so I'm unused to the messages being disposable, even if it happens very rarely. I'm curious how often this pattern can be used. – T.Rob Jan 31 '11 at 20:08
  • @T.Rob: I've never seen it happen, no, but I can imagine high-throughput scenarios where it *would* happen. Also, it's going to depend on your network/VM architecture and JMS implementation. – skaffman Jan 31 '11 at 20:15