Question

If we use JMS request/reply mechanism using “Temporary Queue”, will that code be scalable?

As of now, we don’t know if we will supporting 100 requests per second, or 1000s of requests per second.

The code below is what I am thinking of implementing. It makes use of JMS in a ‘Synchronous’ fashion. The key parts are where the ‘Consumer’ gets created to point a ‘Temporary Queue’ that was created for this session. I just can’t figure out whether using such Temporary Queues is a scalable design.

  destination = session.createQueue("queue:///Q1");
  producer = session.createProducer(destination);
  tempDestination = session.createTemporaryQueue();
  consumer = session.createConsumer(tempDestination);

  long uniqueNumber = System.currentTimeMillis() % 1000;
  TextMessage message = session
      .createTextMessage("SimpleRequestor: Your lucky number today is " + uniqueNumber);

  // Set the JMSReplyTo
  message.setJMSReplyTo(tempDestination);

  // Start the connection
  connection.start();

  // And, send the request
  producer.send(message);
  System.out.println("Sent message:\n" + message);

  // Now, receive the reply
  Message receivedMessage = consumer.receive(15000); // in ms or 15 seconds
  System.out.println("\nReceived message:\n" + receivedMessage);

Update:

I came across another pattern, see this blog
The idea is to use ‘regular’ Queues for both Send and Receive. However for ‘Synchronous’ calls, in order to get the desired Response (i.e. matching the request), you create a Consumer that listens to the Receive queue using a ‘Selector’.

Steps:

    // 1. Create Send and Receive Queue.
    // 2. Create a msg with a specific ID
 final String correlationId = UUID.randomUUID().toString();
 final TextMessage textMessage = session.createTextMessage( msg );
 textMessage.setJMSCorrelationID( correlationId );

    // 3. Start a consumer that receives using a 'Selector'.
           consumer = session.createConsumer( replyQueue, "JMSCorrelationID = '" + correlationId + "'" );

So the difference in this pattern is that we don’t create a new temp Queue for each new request.
Instead all responses come to only one queue, but use a ‘selector’ to make sure each request-thread receives the only the response that is cares about.

I think the downside here is that you have to use a ‘selector’. I don’t know yet if that is less preferred or more preferred than earlier mentioned pattern. Thoughts?

Answer 1

Regarding the update in your post – selectors are very efficient if performed on the message headers, like you are doing with the Correlation ID. Spring Integration also internally does this for implementing a JMS Outbound gateway.