[rabbitmq-discuss] Disk node vs ram node

[Dave Greggory]

Ouch... so no way to ensure that there's something to catch messages when the 
node with the original durable queue goes down?

There are several mentions throughout the site about out-of-the-box live 
failover in future release, how far out is that? 6 months? 1 year?

Not a big fan of the pacemaker approach due to the number of moving parts and 
different packages (pacemaker/corosync/heartbeat/erbd) to maintain and manage. 
And also haven't seen any indication of people actually using that setup in a 
complex VM environment in production.




----- Original Message ----
From: Alexandru Scvorţov <alexandru at rabbitmq.com>
To: Dave Greggory <davegreggory at yahoo.com>
Cc: "rabbitmq-discuss at lists.rabbitmq.com" <rabbitmq-discuss at lists.rabbitmq.com>
Sent: Thu, August 12, 2010 9:33:54 AM
Subject: Re: [rabbitmq-discuss] Disk node vs ram node

Hi Dave,

> When a node with a queue goes down, can I write something using the java client 
>
>that re-declares all known queues on the other node. May be have all the queue 
>names(and params) registered somewhere in the app and upon reconnect, passively 

>re-declare them. If passive declaration throws an exception, catch that and do 
>an actual declaration. Would that work?

If you:
  1) declare a durable queue on one of the clustered nodes,
  2) take down that node,
  3) declare the same queue on another node
you get a "404: Not Found".

If it's not durable, sure.

As an aside, if you passive declare something, then immediately declare
it, the first step is redundant.  There's no problem with declaring
the same thing repeatedly. (assuming it's declared in exactly the
same way and it's not unreachable)

Cheers,
Alex