title: How do I (can I?) detect a RabbitMQ Queue creation failure?
body: <p>I'm trying to work around a race condition in RabbitMQ related to the server not reaping exclusive queues in a timely manner, after a network/socket disconnect, and it's causing the recovery code in the client to fail.  This isn't code that I designed or wrote, and I'm fairly new to RabbitMQ and Spring.  We're also using an older version of spring-rabbit, 1.7.0.RELEASE, so many of the new features that I could use to work around the problem aren't available.  Upgrading to the latest code is an option, but would require a full set of regression tests and we would prefer something simpler as a short term fix that we can get out the door quickly.  We can then roll the upgrade and required changes into a later release where we have the time to test it properly.</p>
  
  <p>The problem is fairly simple.  We have a java server app that creates a named queue that all clients can send messages to.  Our java clients each create a named (name based on the host), exclusive, auto-delete queue to receive messages on from the server.  It's setup as exclusive because we don't want any other client to consume the same queue as all messages to that queue are for the client that created the queue.  I understand that creating named exclusive queues like this is a bad idea and that server generated queue names are preferred, but it's how the system was implemented and fixing it now would require lots of backwards-incompatible changes and lots more testing...</p>
  
  <p>The problem happens on a network failure, where the socket connection goes away.  The client detects this and tries to reestablish the connection, and the queue, etc.  There appears to be a race condition  where the RabbitMQ server doesn't reap the existing queue before the client has retried to create the queue a number of times, failed, and has shutdown the connection.  The RabbitMQ server does, eventually, reap the queue, but by then the client has failed and doesn't recover.</p>
  
  <p>To work around the problem I tried creating the queue non-exclusive, and setting the consumer to exclusive (which it actually was already).  That works fine and solves the race condition.  However, having the queue not be exclusive can cause a significant side effect in an error situation that is avoided by the exclusive queue.  If a second client (client2) is incorrectly configured and tries to use the queue name already being used by another client (client1), the queue creation fails, but the connection stays open, so client2 can still send messages to the server, as if it was client1.</p>
  
  <p>The exclusivity of the queue caused the connection to fail, thus breaking the entire connection, and rendering client2 unable to communicate with the Rabbit server in either direction.  Removing the queue exclusivity and relying on consumer exclusivity means that client2 can't consume any messages from client1's queue, but it can still send messages to our server as if it was client1.  This causes control of client1 to break badly as the server gets conflicting state information from two different clients.</p>
  
  <p>What I'd like to do, short-term, is try to detect that the Queue creation failed on client2, and shut down the connection just like what happens when it fails with the exclusive queue, so that client2 fails, but doesn't also cause client1 to fail.  However, I can't figure out what to do to detect the failure.  Is there a way to do this?  I can't seem to find anything either in the documentation or the Spring AMQP code.</p>
  
  <p>Suggestions?</p>