Thanks again for the response Emile. We've given up on fixing the problem for now &amp; will try, as you've noted, blowing away the DB in order to start fresh.&nbsp;After trying to duplicate the issue I can't find any way to replicate it. Multiple attempts of restarting the process, restarting the consumer in a running process all yield a fully working queue.&nbsp;<div><br></div><div>The event which originally triggered this was our shovel had got into a bad state so we used a 'shutdown -r now' to simply restart the server which evidently failed at the point it was trying to shutdown the broker. At this point the broker was hard-rebooted and came back up with the error i posted here. If you're interested enough in me trying to replicate this issue again i wouldn't mind trying but it does seem like its a rather unique case. Our versions are:&nbsp;<span style="color: rgb(72, 72, 72); font-family: Verdana, sans-serif; font-size: 12px; ">RabbitMQ&nbsp;</span><b style="color: black; font-family: Verdana, sans-serif; font-size: 12px; ">2.8.2</b><span style="color: rgb(72, 72, 72); font-family: Verdana, sans-serif; font-size: 12px; ">&nbsp;on Erlang&nbsp;</span><b style="color: black; font-family: Verdana, sans-serif; font-size: 12px; ">R15B01.</b><br><br>On Thursday, April 4, 2013 9:11:00 AM UTC-6, Jonathan Schwietert wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><span style="border-collapse:separate;color:rgb(0,0,0);border-spacing:0px"><font size="2"><font face="arial, sans-serif">Again, p</font><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">asting in a response i received via email that isn't showing up on this list, from&nbsp;</span><font face="Helvetica" style="font-family:'Times New Roman';color:rgb(34,34,34)"><b>Emile Joubert:</b></font></font></span><div><span style="border-collapse:separate;border-spacing:0px"><font face="Times New Roman" size="2"><b><br></b></font><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">Hi Jonathan,</font><br><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">On 03/04/13 17:28, Jonathan Schwietert wrote:</font><br><blockquote type="cite" style="color:rgb(0,0,0);font-size:medium;font-family:'Times New Roman'">Thanks for the quick response Emile. I did happen to see that result in<br></blockquote><blockquote type="cite" style="color:rgb(0,0,0);font-size:medium;font-family:'Times New Roman'">my searching but unfortunately our broker is standalone - so there are<br></blockquote><blockquote type="cite" style="color:rgb(0,0,0);font-size:medium;font-family:'Times New Roman'">no other nodes to bring up.<br></blockquote><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">If your broker has only ever been standalone then the explanation that</font><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">involves another broker does not apply, though that is the only way I</font><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">know of to replicate the error condition. If you can recreate the error</font><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">with a small sequence of steps then please post them. The only way to</font><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">recover from the error is to move or delete the broker database directory.</font><br><br><font face="Times New Roman" style="color:rgb(0,0,0);font-size:medium">-Emile</font></span><br><br>On Wednesday, April 3, 2013 10:28:46 AM UTC-6, Jonathan Schwietert wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';border-spacing:0px;font-size:medium">Thanks for the quick response Emile. I did happen to see that result in my searching but unfortunately our broker is standalone - so there are no other nodes to bring up.</span><br><br>On Wednesday, April 3, 2013 10:28:02 AM UTC-6, Jonathan Schwietert wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Pasting in a response i received via email that isn't showing up on this list, from <font face="Helvetica"><span style="font-size:14px"><b>Emile Joubert:</b></span></font></div><div><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';border-spacing:0px;font-size:medium">Hi,<br><br>On 02/04/13 23:32, Jonathan Schwietert wrote:<br><blockquote type="cite">Hi, I have a queue which was declared with BOTH durable and exclusive<br></blockquote><blockquote type="cite">(on accident) whose owner disconnected then reconnected and now<br></blockquote><blockquote type="cite">receives: "NOT_FOUND - no queue 'test.queue' in vhost '/test.vhost'".<br></blockquote><br>See the documentation for the exclusive parameter:<br><br><a href="http://www.rabbitmq.com/amqp-0-9-1-reference.html#queue.declare.exclusive" target="_blank">http://www.rabbitmq.com/amqp-<wbr>0-9-1-reference.html#queue.<wbr>declare.exclusive</a><br><br>"Exclusive queues may only be accessed by the current connection, and<br>are deleted when that connection closes."<br><br>So your 'test.queue' should not longer exist. The presence of the string<br>in the internal Mnesia files does not necessarily mean that the queue<br>still exists since the name could appear in internal logs.<br><br>The scenario you describe can occur if a queue was declared on a node<br>which leaves a cluster. A "Not Found" error will result when attempting<br>to redeclare or delete the queue on any remaining nodes in the cluster.<br>The solution is for the node that left the cluster to rejoin. The use of<br>mirrored queues will prevent this condition.<br><br><br>-Emile</span><br></div></blockquote></blockquote></div></blockquote></div>