[rabbitmq-discuss] Cluster Pathology

[Jason J. W. Williams]

Hi Dmitriy,

> I have thought more about it and now I'm wondering if it's even possible to
> redeclare a queue in a cluster that happens to reside on a node that
> currently is not reachable from cluster? Can't test at the moment, since I
> decommissioned my cluster vms some time ago :)
>
> In theory, doesn't the queue still exist when queue.declare with active=true
> is attempted? The contents might not be replicated, but all metadata are.

That's not been my experience. Neither queue contents or metadata seem
to be replicated.

>
> Have you actually tried it? I kind of expect that if you don't remove a node
> from cluster, you won't be able to redeclare a queue. Does this sound
> reasonable?

You can redeclare the queue if a node is down. It seems to override
the existing declaration when the formerly dead node rejoins.


> I am also primarily looking at cluster for failover capabilities. I am
> getting better failover from unclustered brokers - an alternative approach
> that Tony described earlier today in another thread [1]. YMMV of course.

That's the road we've started going down. We were going to give Qpid a
shot, but it doesn't work on OpenSolaris (particularly the persister).
Unclustered Rabbit nodes eliminates the orphaned consumer problem. In
RAS terms, RabbitMQ clustering seems to only provide the A. It seems
to me on a node failure, either Rabbit needs to migrate an empty
version of the queue to another node, or send a "you're dead" notice
to consumers attached to the queue via nodes that aren't hosting the
queue. Also, if the queue has been redeclared, there optimally would
be a way for the dead node to replay its messages (if desired) into
the recreated queue(s) when it comes back up.

-J