<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>I've noticed a pattern here that seems to be consistently reproducible.</div><div><br></div><div>In our setup, we have three RabbitMQ 2.71 brokers in a cluster on Ubuntu 10.04. They're all mirroring the same set of queues, but that may or may not be relevant here.</div><div><br></div><div>Starting from a healthy state (Management web console showing all brokers, and all queues in sync), I simply run "rabbitmqctl stop_app" for one of the nodes, followed by running "rabbitmqctl start_app" on the same node.</div><div><br></div><div>The expected results is that the one broker should drop out of the cluster, then rejoin it. This is indeed what happens when I run against a broker that does *not* have the stats database (as shown by the Web UI).</div><div><br></div><div>If I try this action on the node with the stats database, rabbitmqctl waits forever and I have to ctrl-c out. If I then try "rabbitmqctl stop", it errors out, saying that the node is down.</div><div><br></div><div>The only way I can get the cluster back up is to shut down the other two actively running nodes, then restart all three nodes.</div><div><br></div><div>Known issue? Something I'm overlooking? Searching online isn't turning up anything obvious.</div><div><br></div><div>Thanks,</div><div><br></div><div>Matt</div><div><br></div></body></html>