I've heard this is a bug in 2.8.2. It's caused by an alarm related to disk space or RAM space going off at startup. Unfortunately the node never recovers from this condition. The workaround is to ensure that sufficient disk/RAM is available when the node powers up.<div><br></div><div>-Glade<br><br>On Wednesday, May 23, 2012 1:09:06 AM UTC-7, Eric Siroker wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I've encountered the same issue. &nbsp;I believe it's a regression in RabbitMQ 2.8.2. &nbsp;Neither 2.7.1 nor 2.8.1 exhibit this issue for me.<div><br></div><div>I'm including two test cases, one using&nbsp;amqplib and one using Pika.</div><div><br></div><div>Running a two node cluster with&nbsp;RabbitMQ 2.8.2, these test cases will succeed on one node, but fail on the other.</div><div><br></div><div>If you restart&nbsp;RabbitMQ on one of the nodes, it'll sometimes switch which node makes the test cases succeed.</div><div><br></div><div>Eric<br><div><br></div><div>======&nbsp;amqplib test case</div><div><div>from amqplib import client_0_8 as amqp</div><div><br></div><div>connection = amqp.Connection(host='', username='', password='')</div><div><br></div><div># Raises socket.error: [Errno 104] Connection reset by peer</div><div>connection.close()</div></div><div><br></div><div>====== Pika test case<br></div><div><div>import pika</div><div><br></div><div>credentials = pika.PlainCredentials(<wbr>username='', password='')</div><div>connection_parameters = pika.ConnectionParameters(<wbr>host='', credentials=credentials)</div><div>connection = pika.BlockingConnection(<wbr>connection_parameters)</div><div>channel = connection.channel()</div><div><br></div><div># Raises pika.exceptions.ChannelClosed</div><div>channel.exchange_declare(<wbr>exchange='exchange')</div></div></div></blockquote></div>