Announcement Announcement Module
No announcement yet.
Message Listener container doesn't set the correlation id on the reply message Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Message Listener container doesn't set the correlation id on the reply message


    I'm testing rabbitMQ using spring but seem to have hit a problem for which I don't see an immediate solution. I'm trying to do RPC over rabbitMQ.

    I have a setup with 2 applications running on a tomcat. The first one uses the rabbitTemplate to send a message to an exchange. This template is configured to set a replyTo queue header on the outgoing message, which I can see using the rabbit web console. However, My "server" application which has a message listener container is not setting the correlation Id on the reply message. So, the rabbitTemplate of the "client" application never receives the response although the message is on the reply queue (or doesn't he need the correlation Id at all and is there something else going wrong?). If I don't set a replyTo queue, and do a convertSendAndReceive on the rabbit template it seems to be working perfectly but I don't want to performance hit off creating a temporary queue on each RPC call...

    An other question: When doing RPC, is it wise to create a fixed replyTo queue for all RPC calls ? because this would mean that the rabbitMQ template would try to fetch a reply message from a queue which can contain multiple replies which is not necessarily meant for him? I assume that it's better to create a reply queue dedicated for each remote message invocation?

    Thx in advance!

  • #2
    When using a fixed reply queue, you need to add a <reply-listener/> element to the rabbit template - the template uses a listener container to receive the reply messages and correlates the reply to a particular request. If you are not using the XML namespace to configure your template, you have to instantiate a SimpleMessageListenerContainer with the template as its listener.

    However, in either case, the server side MUST return the correlation data in the reply.

    The listener container and correlation is needed because there might be multiple concurrent threads sending (and receiving) messages; that's why the earlier implementation only used temporary queues. The fixed queue feature was added to improve performance but it comes at the expense of more complexity, including message correlation.

    In 1.1.x, a custom message property was used for correlation; in the upcoming 1.2 release (currently at milestone 1 - 1.2.0.M1) the standard 'correlationId' property is used by default, but you can chose your own property. In either case, though the server side has to return it in the right message property.

    When using Spring Integration, the inbound gateway takes care of this for you.

    Yes, you need a fixed reply queue for each sender; unlike JMS, RabbitMQ doesn't have the notion of a message selector; with JMS we can use a shared queue and only receive messages that match a selector expression.


    • #3
      Hi Gary,

      Thx for the information, I've set up a SimpleMessageListenerContainer but it seems that on the server side, where I'm also using a SimpleMessageListenerContainer which uses a JsonConverter is not setting the correlationId back on the reply message.
      How do I configure The MLC on the server side to "keep" the correlationId and set it on the outgoing reply message ?

      I've extended the JsonConverter and used a ThreadLocal to store the correlationId and put it back on the reply message. Is that the correct way to do it?
      Last edited by Domenique; May 27th, 2013, 01:14 AM.


      • #4
        Is that the correct way to do it?
        I think yes.
        The starting point to understand "How to?" here: MessageListenerAdapter and it's method postProcessResponse



        • #5
          Right; the container itself doesn't send replies; if you are sending your own reply you have to set up the correlation id yourself in the reply.

          If you are using a MessageListenerAdapter it will send the reply for you (assuming your POJO listener method returns a result).