Hi,


Here's my scenario:


I have multiple instances of listeners waiting on one queue and each of them
have a unique id to correlate the message. The message published by the
publisher will have a correlation id and each listener should only pick the
message that matches the correlation id.


I read that this is possible in case of RPC where in you will pass a call
back queue reference and correlation id while publishing the message. But my
scenario is different.


Please let me know whether there is a straight forward solution for this.


Regards,
Antony.






--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/Consume-message-based-on-correlation-Id-tp27224.html
Sent from the RabbitMQ mailing list archive at Nabble.com.

Search Discussions

  • Michael Klishin at Jun 6, 2013 at 10:24 am
    2013/6/6 antony <antony.pulicken@gmail.com>

    The message published by the
    publisher will have a correlation id and each listener should only pick the
    message that matches the correlation id.

    Have you considered using one server-named queue per consumer and routing
    keys instead of correlation-id (or in addition to it)?


    Then each consumer will only get deliveries it should work on.
  • Antony at Jun 6, 2013 at 11:57 am
    Did you mean the temporary queues created/managed by the server ? I
    considered it, but then we will end up creating a new queue for each request
    in my scenario and that's when I started thinking about a less expensive
    option.




    Regards,
    Antony.






    --
    View this message in context: http://rabbitmq.1065348.n5.nabble.com/Consume-message-based-on-correlation-Id-tp27224p27227.html
    Sent from the RabbitMQ mailing list archive at Nabble.com.
  • Antony at Jun 6, 2013 at 12:31 pm
    To make it more clear, I'm looking at something that is equivalent to JMS
    correlation ID.


    http://stackoverflow.com/questions/149037/jms-message-receiver-filtering-by-jmscorrelationid










    --
    View this message in context: http://rabbitmq.1065348.n5.nabble.com/Consume-message-based-on-correlation-Id-tp27224p27228.html
    Sent from the RabbitMQ mailing list archive at Nabble.com.
  • Michael Klishin at Jun 6, 2013 at 12:55 pm
    2013/6/6 antony <antony.pulicken@gmail.com>

    Did you mean the temporary queues created/managed by the server ? I
    considered it, but then we will end up creating a new queue for each
    request
    in my scenario and that's when I started thinking about a less expensive
    option.

    Named, to be more precise. If you specify queue name as an empty string,
    RabbitMQ
    will generate a unique one and send it back with the queue.declare response.


    If your queues are short lived and only contain a single response, create
    them as non-durable.
    It's unlikely to introduce a lot of overhead, although it will lead to more
    network roundtrips but
    will reduce the amount of messages your consumers have to requeue because
    they have different
    correlation ids.


    Which I am guessing will reduce the overall amount of traffic.
  • Antony at Jun 6, 2013 at 1:05 pm
    Ok..got it.. ! Thanks MK!


    I was actually looking for something that is equivalent to JMS correlation
    ID.


    http://stackoverflow.com/questions/149037/jms-message-receiver-filtering-by-jmscorrelationid






    --
    View this message in context: http://rabbitmq.1065348.n5.nabble.com/Consume-message-based-on-correlation-Id-tp27224p27230.html
    Sent from the RabbitMQ mailing list archive at Nabble.com.
  • Michael Klishin at Jun 6, 2013 at 1:15 pm
    2013/6/6 antony <antony.pulicken@gmail.com>

    I was actually looking for something that is equivalent to JMS correlation
    ID.


    http://stackoverflow.com/questions/149037/jms-message-receiver-filtering-by-jmscorrelationid

    Messaging "filtering" (routing) in RabbitMQ happens between queues, not
    consumers.


    I'm not a JMS user but it sounds like the solution with temporary queues
    and routing keys
    used for correlation provide roughly the same functionality.


    I also suspect projects such as Spring messaging integration may provide a
    higher level interface
    that's closer to JMS.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJun 6, '13 at 10:20a
activeJun 6, '13 at 1:15p
posts7
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Antony: 4 posts Michael Klishin: 3 posts

People

Translate

site design / logo © 2017 Grokbase