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

Arun Suresh arun.suresh at gmail.com
Thu Feb 18 04:06:00 GMT 2010


Hi

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. Let me
explain:

1) Assume we have a cluster of RabbitMQ nodes... 'rabbit at host1' and
'rabbit at host2'
2) 'client1' connects to 'rabbit at host1', declares an exchange 'test_x' and
then declares a q 'test_queue' and binds to it.
3) 'client2' being of the same codebase as 'client1' on starting up connects
to 'rabbit at host2' and does the same thing as 'client1'.

At this point of time, If we do a 'rabbitmqctl list_queues consumers name
node' the response we get is:

2        test_queue         rabbit at host1

Our reason for doing this was that a message sent to the 'test_x' exchange
would be consumed by either of the clients.

Now..

4) Assume 'rabbit at host1' node goes down (machine crash, becomes
unreachable... whatever)
5) 'client1' detects the outage and tries connecting to 'rabbit at host2'...
and the mq connection startup code kicks in.. thus.. the queue 'test_queue'
is recreated on 'rabbit at host2'

Now... If we do a 'rabbitmqctl list_queues consumers name node' the response
we get is:

1        test_queue         rabbit at host2

As u can see we have only one consumer...

To fix this isuue... we get 'client1' to notify all other clients of a
network outage.. 'client2' intercepts this message and promptly reconnects
to 'rabbit at host2' and again binds to 'test_queue'.
Everyone is happy...

Unfortunately... we have noticed that from 1.7.1, step 4 goes for a toss..

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 ??
Which means there wont be any consumers for messages sent to the exchange
for the duration of the outage..

I was wondering if anybody could probably shed some light on :
1) Why this change in behaviour ?
2) What is the suggested approach to tackle these types of availability
issues in rabbitMQ ?

Thanx in advance
-Arun Suresh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100218/09f5aada/attachment.htm 


More information about the rabbitmq-discuss mailing list