Thanks Simon.<br><br>Just to make sure I understand fully, does the problem scenario I described actually occur?<br><br>That is, if the aliveness-test queue lives on mq1 and mq1 is unresponsive, and I then hit the mq2 broker with an /api/aliveness -test request, you'd expect that request to either time out or take a long time?<br>
<br>Thanks,<br><br>Matt<br><br><div class="gmail_quote">On Fri, Oct 26, 2012 at 3:52 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>On 26/10/12 01:18, Matt Pietrek wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If this is an issue, I'm wondering if there are alternative, "approved"<br>
manners of checking the health of an individual broker within a cluster?<br>
</blockquote>
<br></div>
aliveness-test declares a queue, publishes a message, and basic.gets it. You could do that.<br>
<br>
Cheers, Simon<span><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br>