Hello, <br><br>Although this is my first post to the rabbitmq-discuss
list, I've enjoyed reading the archives over the last few days. We're
evaluating rabbitmq for a system at work. One apparent limitation that
we've run into is that while exchange information (which node a queue
lives on, etc.) is replicated each node itself seems to be a single
point of failure in that if it goes down then a message whose routing
key only matches bindings to queues on that node will be dropped. That
is, from what I understand it appears that although the contents of
persistent queues are /recoverable/ in the event of a disaster I don't
see a built-in way of having another node in the cluster "take over" a
queue which previously lived on a node which has just gone down.<br><br>I'd
like to know whether a) I've missed something in my interpretation of
how rabbitmq server handles persistent queues in a cluster and b) if
this is indeed the current behavior what other rabbitmq users have done
to provide fault tolerance.<br>
<br>I appreciate any insight into how people solve these issues with rabbitmq. Thanks in advance.<br>
<br>-Charles<br>