[rabbitmq-discuss] Behaviour change from rabbitMQ v1.7.0 to v1.7.1

[Matthias Radestock]

Arun,

apologies for the late reply. We have been rather busy (even more so 
than usual).

Arun Suresh wrote:
> We are currently using RabbitMQ 1.7.0 and we'd like to move to 1.7.2 but 
> we have noticed a fundamental behavior change across these versions. 
> [...]
> if 'rabbit at host1' goes down, 'client1' cannot recreate 'test_queue' on 
> 'rabbit at host2'.
> Do this imply that... all queues created on the node WILL be unavailable 
> for the duration of the nodes outage ??

It has always been the case that when a queue's host node goes down that 
the queue is unavailable for the duration of the outage. However, 
previously it was possible to create a queue *with the same name* on a 
different node. That queue was *not* the same logical queue, and its 
creation could result in observable client behaviour that violates the 
AMQP spec and is surprising to users (you'll find a few reports on the 
mailing list), e.g. messages suddenly vanish and re-appear on node 
restart. There were also cases where the persister would get confused, 
and message duplication could occur.

> 2) What is the suggested approach to tackle these types of availability 
> issues in rabbitMQ ?

The objective of RabbitMQ's current clustering approach is scalability. 
It does little to improve availability. For the latter there are several 
approaches, depending on what exactly you need to have available and 
whether short outages are acceptable. One common solution is to have a 
hot standby broker, i.e. have an active/passive setup. iirc this has 
been discussed on the list before, so a search should throw up some results.


Regards,

Matthias.