<div dir="ltr">As an additional piece of information, the cluster consists of two nodes, with the queue in question (and indeed all queues) mirrored, with their home on node A. All the stuck connections are homed on node A. Consumers and publishers connect to either node using a load balancer.<div><br></div><div>We've just forced our temporary queue (which also started exhibiting the same problem) to have node B as its home, and now any workers that attempt to consume from node A have an error:</div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Bunny::NotFound: NOT_FOUND - home node 'rabbit@nodeA' of durable queue 'temp_queue' in vhost '/' is down or inaccessible</blockquote><div><br><div>Cluster status seems to be ok. Now that we only have consumers on node B, we're going to leave it for a while and see if we have any stuck connections. We may attempt to split and rejoin node A from the cluster to see if it remedies things.</div><div><div><br></div><div><br>On Wednesday, 14 August 2013 10:41:13 UTC+1, Paul Bowsher  wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Hi,<div><br></div><div>After the upgrade to RabbitMQ 3.1.4 we're seeing a large number of linearly-increasing channels which seem to hang around after the connection is closed. This doesn't happen on every queue (even those processed by the same software), only on a particular queue. The orphaned channels leave 20 messages (the prefetch count) unacked.</div><div><br></div><div>Symptoms:</div><div><br></div><div>- Initially, larger than expected consumer count on queue from our monitoring</div><div>- Stopping all expected consumers on that channel removes the expected number of consumers, leaving orphans (700+ at present)</div><div>- Each orphaned consumer's channel is reachable using Management tool</div><div>- Each connection for the channel is reachable, is in either a "flow" or "blocked" state with zero data flow. Timeout is set to 600s (count doesn't decrease after 10 minutes)</div><div>- Forcing a stuck connection closed through the management interface results in a 500:</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The server encountered an error while processing this request:<br>{exit,{normal,{gen_server,<wbr>call,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; [&lt;0.16806.1347&gt;,<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;{shutdown,"Closed via management plugin"},<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;infinity]}},<br>&nbsp; &nbsp; &nbsp; [{gen_server,call,3,[{file,"<wbr>gen_server.erl"},{line,188}]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{rabbit_mgmt_wm_connection,<wbr>delete_resource,2,[]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{webmachine_resource,<wbr>resource_call,3,[]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{webmachine_resource,do,3,[]}<wbr>,<br>&nbsp; &nbsp; &nbsp; &nbsp;{webmachine_decision_core,<wbr>resource_call,1,[]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{webmachine_decision_core,<wbr>decision,1,[]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{webmachine_decision_core,<wbr>handle_request,2,[]},<br>&nbsp; &nbsp; &nbsp; &nbsp;{rabbit_webmachine,'-<wbr>makeloop/1-fun-0-',2,[]}]}</blockquote><div><br></div><div>- The connection closure does actually succeed, and the count drops.&nbsp;</div></div><div>- Forcing a normal connection closed still works correctly.<br></div><div>- Doing a netstat on both the client and server shows that the port associated with the connection is indeed completely closed, and not in any sort of TIME_WAIT or FIN_WAIT state</div><div><br></div><div>This issue occurred over the weekend, but as it was unchecked it eventually exhausted the server of socket descriptors, and we had to restart RabbitMQ to recover. It's happened again over night. We can't see anything in our client or server logs that give any indication as to the cause of it. We upgraded from 3.1.0 so unfortunately are unable to determine which version is responsible for the bug, if indeed it is a bug.</div><div><br></div><div>If anyone has seen this behaviour or has any suggestions, please let us know. Also, if we can provide any debug data let us know.</div><div><br></div><div>Thanks,</div><div><br></div><div>Paul Bowsher</div></div></blockquote></div></div></div></div>