Announcement Announcement Module
No announcement yet.
Request/Reply with JmsOutboundGateway and Reply-Topics Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Hi Mark,

    your solution looks good so far. The drawback imho is that one cannot use the standard JMS MessageId. That might be a problem when communicating with systems that use the "standard" pattern (messageId <-> correlationId).

    I wonder if it would be possible to provide an alternate solution that works without the JMS message selector at all. The JmsOutboundGateway could then filter the messages based on the JMS MessageId itself. Something like this (dummy code):

    // Create a consumer that consumes every message on replyTo-destination
    messageConsumer = session.createConsumer(replyTo);
    // Send Request
    String expectedCorrelationId = jmsRequest.getJMSMessageID();
    // Wait for reply
    while (true) { // TODO check timeout 
      Message reply = consumer.receive();
      if (expectedCorrelationId.equals(reply.getJMSCorrelationID())) {
        // Reply received
        return reply;
    What do you think?



    • #17
      Hi Mark,

      any thoughts on my previous my last post? For us it would be very useful if we could use the jmsMessageId/correlationId. So it would be helpful to have a solution not based on the JMS message selector.



      • #18
        Actually, I'm a little confused about the question. If no 'correlation-key' is configured, we are expecting the outbound MessageID to be present on inbound reply Messages as the CorrelationID. That is why we do provide a MessageSelector for that.


        • #19
          With your fix I now have two choices when dealing with (non-temp, non-durable) Topics for Reply messages:

          1. use the default JMS messageId
          2. use a generated UUID-based messageId that the receiver of the message has to send back so that you can query for it using the message selector

          The first option has the disadvantage that messages can get lost when they are received betweend sending and starting the consumer)
          The second option has the disadvantage that a receiver needs to be aware of an additional (" proprietary") message header field that it has to add to it's reply. This is not an option if the receiver's behaviour cannot be influenced.

          A third option could be: use the JMS MessageId but skip the message selector (as mentioned in Thread-Post #16 above) and let the JmsOutboundGateway select the messages itself. Since the MessageConsumer is constructed before the request is sent, it collects all messages on the replyTo-destination until they are received (by the JmsOutboundGateway). No message can get lost due to race conditions. I've tried this in a very simple test case (no Spring Integration involved) and it worked well.