[rabbitmq-discuss] Re-creation of queues not allowed
matthias at lshift.net
Sun Feb 21 12:11:17 GMT 2010
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
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.
More information about the rabbitmq-discuss