Hi,<br><br>� Hmm... ok, I&#39;ve checked the AMQP specs and now I see, that the if-unused flag for queues is different than the is-unused flag for exchanges. I thought the two would be the same.<br><br>Thanks and have a great weekend,<br>
�� Peter<br><br><div class="gmail_quote">2010/3/6 Martin Sustrik <span dir="ltr">&lt;<a href="mailto:sustrik@250bpm.com">sustrik@250bpm.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Peter,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 �I have an interesting problem (I&#39;m using version 1.7.0 of the broker): both the exchange.delete and queue.delete have a if_unused flag. The specs state, that if the if_unused flag is true, then an exchange will only be deleted if it does not have any bindings (basically I don&#39;t have to keep track of everything, but simply ask the server to only delete if nobody is using it any more). Now my problem is, that the queue.delete also has such a flag, but alas does nothing (and I also haven&#39;t found any infos about it). My reasoning would be that it should do exactly the same thing: if there are exchanges still bound to the queue, it shouldn&#39;t be deleted, nonetheless it deletes it. Any ideas why this strange behaviour?<br>

</blockquote>
<br></div>
Here&#39;s what AMQP documentation says:<br>
<br>
 � � �The server SHOULD allow for a reasonable delay between the point<br>
 � � �when it determines that a queue is not being used (or no longer<br>
 � � �used), and the point when it deletes the queue. �At the least it<br>
 � � �must allow a client to create a queue and then create a consumer<br>
 � � �to read from it, with a small but non-zero delay between these<br>
 � � �two actions. �The server should equally allow for clients that may<br>
 � � �be disconnected prematurely, and wish to re-consume from the same<br>
 � � �queue without losing messages. �We would recommend a configurable<br>
 � � �timeout, with a suitable default value being one minute.<br><font color="#888888">
<br>
<br>
Martin<br>
</font></blockquote></div><br>