Hello, <br><br>Although this is my first post to the rabbitmq-discuss
list, I&#39;ve enjoyed reading the archives over the last few days.� We&#39;re
evaluating rabbitmq for a system at work.� One apparent limitation that
we&#39;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&#39;t
see a built-in way of having another node in the cluster &quot;take over&quot; a
queue which previously lived on a node which has just gone down.<br><br>I&#39;d
like to know whether a) I&#39;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>