[rabbitmq-discuss] Round-robin queue failover

Mon Oct 26 17:10:17 GMT 2009

The solution we use is pretty much what Alexis describes. No  
clustering. And both consumers and producers declare queues on a fail  
over to a hot standby/passive server. That way messages are never  
lost. When the old server comes back up we fail back.

-J

Sent via iPhone

On Oct 26, 2009, at 10:23, Alexis Richardson <alexis.richardson at gmail.com 
 > wrote:

> Sebastian
>
> On Mon, Oct 26, 2009 at 4:04 PM, Sebastian <mail at sebastian-latza.de>  
> wrote:
>>
>> Kyle Schaffrick:
>>
>>> Attempting to create two identically-named queues will
>>> result in declaring the same queue twice; the two consumers then
>>> consuming from that queue will see load-balancing behavior.
>>
>> Thanks for the clarification. Since this does not work: how do I
>> achieve reliable persistent message delivery even if the one node
>> holding the queue dies?
>
> At the risk of being seen as pedantic...
>
> You could achieve it by waiting for the node to recover from disk.  In
> other words: RabbitMQ provides "eventual delivery" out of the box.  If
> you want to 'persist more reliably' than on one drive using RabbitMQ
> out of the box, then use a RAID or a SAN.
>
> I am guessing that what you mean is *availability* in which a message
> can always reach a suitable queue even if the sending client loses its
> connection with the node that crashed.  The problem with using a
> single node is the time it takes to recover, and client reconnection
> costs (if any).  The time to recover is partly influenced by how much
> state has to recover, and partly by the size of the unavailability
> window that you can tolerate.
>
> Many applications don't like to wait more than (say) 1ms, 10ms or 50ms
> before they can send their message.  In this case you will typically
> want to send a message *before* the crashed node has been able to
> recover.  You can achieve this in two ways:
>
> 1. You don't care about replicating state and can use any other queue
> as a 'suitable queue'.  This is easy - just make sure the right
> consumers and routes are wired up.
>
> 2. You do care about replicating state - which I think is the case you
> have in mind.  Then you can fail over to a passive server.  We can
> provide some more info on this if you like -- we have done it for a
> few people but it is not yet 'available OOTB'.  (You can also do
> active/active but it is much more fiddly atm).
>
>
>
>> As stated before my take would be to replicate
>> queues client-side on independent brokers, but this seems to be
>> getting quite complicated as the queues have to be "double-declared",
>> linked and properly re-initialized on startup of a new empty broker
>> (basically doing some kind of client-side clustering).
>
> Right.  I think you probably want case 2 above.
>
> alexis
>
>
>
>> Regards
>> Sebastian
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss