Thanks Simon.<br>
<br>
I realized just now that I was less than precise in my prior summary of the state.<br>
<br>
It does appear that that rabbitmqctl and the management API are in sync on what they report.
What's "interesting" is that after the broker rejoins the cluster, it's not always a slave for the queues it was previously a master or slave for.<br><br>If you'll recall from my original message, we normally have 3 brokers. During the rolling upgrade we take one down and then rejoin it to the cluster. What we're seeing is that after the broker rejoins, some of the queues have the expected two slaves ('+2' in the UI). However, other queues (seemingly at random) have only one slave ('+1').<br>
<br>The management UI and rabbitmqctl agree on what we're seeing. And prior to the operation, all the queues had two slaves.<br><br><br><div class="gmail_quote">On Fri, Jun 22, 2012 at 4:45 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 20/06/12 22:31, Matt Pietrek wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Back before 2.8.0 was announced, I reported an issue with Mirrored<br>
queues reporting some nodes as unsynchronized.<br>
</blockquote>
<br></div>
Hmm. Well, there was a real issue there. That one was where the management plugin was getting desynchronised from what was really going on. So if you are still seeing something similar in 2.8.2, does management agree with rabbitmqctl?<br>
<br>
(In general rabbitmqctl goes and calls into processes whenever it needs to know something, while management listens to events that are broadcast and maintains its own view of the world.)<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br>