[rabbitmq-discuss] Behaviour change from rabbitMQ v1.7.0 to v1.7.1
matthias at lshift.net
Sat Feb 20 10:46:21 GMT 2010
apologies for the late reply. We have been rather busy (even more so
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.
More information about the rabbitmq-discuss