2

I have tried to search my question for several days but found no satisfying solutions.

So here is my situation:

I have an application runs on different nodes, say 3. Each application on each of these 3 nodes needs to consume same messages.

How can I achieve this?

Below are some approaches I have tired :

  1. Binding 3 consumers/nodes to one queue. The problem is that RabbitMQ uses round-robin strategy to ensure load balance. So for each message there will be only one consumer.

    Possible solution: Is there a way to turn off round-robin strategy ?

  2. Use FANOUT exchange.The problem is that we are using auto-deployment tools so the configuration for each nodes is totally the same, resulting in 3 consumers/nodes declare one same queue. This turn out to be the first failed approach above.
  3. Each application/nodes declares different queues with certain unique and random queue names, and bind these queues to a FANOUT exchange. The problem is when an application disconnects and reconnects with RabbitMQ, it will declare a new queue due to the random queue names, and fail to consume messages that piled up on the earlier queues during the disconnection time.

Thanks in advance for your replies.

Jeff
  • 61
  • 5
  • Seems like RabbitMQ's PubSub is achieved with fanout, so the cleanest solution would be to fix your auto-deployment config. Anything else would be a hackier approach. – Kayaman Jun 30 '17 at 07:04
  • What you said about RabbitMQ's PubSub's achieve is true. As in ActiveMQ, it's Topic/VirtualTopic. In fact, we are transferring from ActiveMQ to RabbitMQ. While in ActiveMQ, this situation can easily be done with Topic. – Jeff Jun 30 '17 at 07:11
  • You might want to modify the title a bit. Clearly you know that it supports PubSub. Just not in the way you want for this particular case. – Kayaman Jun 30 '17 at 07:13
  • regarding the **fanout** approach, if you declate queue with no name, the server will give it a random name, then you can bind it to your fanout exchange, declare that queue as exclusive, and it will be deleted automatically on disconnect, so now each consumer will have it's own queue, and this queue will receive all messages that were sent to the exchange, check this for more details https://www.rabbitmq.com/tutorials/tutorial-three-java.html – Yazan Jul 03 '17 at 09:27
  • @Yazan Hi, thanks for your response. I have a question on this sentence of your comment : `...and this queue will receive all messages that were sent to the exchange...`. As I explained in the 3rd approach, when a consumer disconnects and reconnects with RabbitMQ, it will still miss the messages that were send to the fanout exchange during the disconnection time. – Jeff Jul 04 '17 at 07:49
  • yes that's right, then you may want to have a mix of fanout with a queue per consumer, let the consumer generate it's queue name (unique), store it somewhere (in a file?), let the consumer create the queue, and bind it to the exchange (at startup maybe) if it's already created and bind, then MQ will ignore this procedure and the consumer will always use this queue – Yazan Jul 04 '17 at 08:04

0 Answers0