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

[Matthias Radestock]

Arun,

Arun Suresh wrote:
> 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..)

This is not something the system was designed to do. It is not in the 
spirit of the AMQP spec and only ever half-worked by accident - messages 
recovered in that way would stay in R1's persister forever, resulting in 
message duplication on subsequent restarts. The list received some 
reports of this happening, which prompted us to change the behaviour.

> How do think we should tackle this situation now ?

Depends on whether you can afford to lose some messages in the event of 
a node outage. Presumably you can since even in your existing setup any 
publishes occurring between the time R1 goes down and the queue gets 
re-created on R2 are not enqueued.

Plus if your consumers can keep up then the queues will generally be 
empty anyway.

In that case simply make the queues non-durable and the messages 
non-persistent. That way when R1 goes down the queue well and truly 
disappears and you can re-create it on another node, i.e. your existing 
logic would work just fine.


Regards,

Matthias