[rabbitmq-discuss] Re-creation of queues not allowed

Sun Feb 21 05:18:37 GMT 2010

Hello Mathew..

Thank you for your reply..

> Also, It would be really awesome if somebody would explain to me what is
> the
> > recommended approach to a situation when a node goes down.
>
> Depends massively on your situation. Clustering in Rabbit is meant to
> facilitate scalability, not high availability. If you could provide some
> further details of your scenario, we'd be better able to advise.
>
> Matthew
>
>
Ok.. Here is a very simplistic description of our setup..

Assume we have 2 rabbit nodes.. R1 and R2.
and 2 Clinets C1 and C2 (running the same code-base). C1 on startup creates
a connection to R1, creates and subscribes to a queue 'Q'. C2 on startup
creates connection to R2 and subscribes to the same Q. So now we have Q
created on R1 but 2 consumers subscribing to it.

Q is bound to a direct exchange X. The idea is that a producer might publish
an event on X.. which can be handled by either C1 or C2.

Up until now (since we were using Rabbit 1.7.0), If say R1 goes down, C1 is
notified (since it is connected to R1) so C1 reconnects to R2 and recreates
the Q on R2.. it also notifies C2.. so C2 can re-connect to R2 and
re-subscribe to the new queue (also named Q)..
Thus... Thus any event sent on X will still be routed to C1 or C2. (Only
caveat is... when R1 comes back, all messages that were in the Old queue is
appended to the New queue.... since we arnt really particular about the
ordering.. that should be fine..)

How do think we should tackle this situation now ?

Thanx in Advance
-Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100221/464414e3/attachment.htm 