[rabbitmq-discuss] Queue Lease (x-expires)

Mon Jan 23 17:27:26 GMT 2012

Yogesh,

I don't believe there is a possibility of deadlock in this situation. It is
possible that the second client will declare the queue and that it is then
deleted (by the first client) before it can start using it, but no deadlock will
occur.

However, there is a window between Declaring a queue and it being 'in use'
(which means there is a Consumer subscribed), so that publishers that declare
before use, and consumers that declare before use, might have the queue removed
from them just when they don't want it removed.

The Consume will fail if the queue disappears, so some retry logic is all that
is needed on the Consumer client app.

Publishing to a non-existent queue is quite OK -- no failure there, so some
options on the publish would need to be employed to ensure that the message
reaches its destination.

I'm not sure what a fail-safe solution to the declare-publish window is, so I'll
ask my colleagues.

Hope this is useful,
Steve Powell  (a loppy bunny)
----------some more definitions from the SPD----------
vermin (v.) Treating the dachshund for roundworm.
chinchilla (n.) Cooling device for the lower jaw.
socialcast (n.) Someone to whom everyone is speaking but nobody likes.

On 23 Jan 2012, at 14:33, Yogesh Ketkar wrote:

> Thanks Steve.
> 
> I am planning to write a Java Client which will get list of queues
> using something like
> Process proc = Runtime.getRuntime().exec("rabbitmqadmin.py list queues
> name -f bash") and then iterate over each queue name
> and call
> channel1.queueDelete(queueName, true, true)
> 
> Just one question.
> Assume that this client is trying to delete the queue on one channel
> and and some other client is trying to do
> channel2.queueDeclare as it wants to publish a message on the same
> queue.
> Is there a chance of deadlock due to timing of these 2 calls, on two
> different channels, channel1.queueDelete and channel2.queueDeclare?
> 
> regards, Yogesh
> 
> 
> On Jan 23, 5:23 pm, Steve Powell <st... at rabbitmq.com> wrote:
>> Yogesh,
>> 
>> rabbitmqadmin can delete the queue but without the checks that it might not be
>> empty and might be being used.  If you can be sure that the queue is dead, then
>> a rabbitmqadmin check followed by a delete would be quite adequate.
>> 
>> However, if it is possible that the queue might not be dead (just usage being
>> slow) or it might be reused, then it is imperative that the delete be
>> conditional.  The java client interface (or some other client interface) should
>> be used to make the delete conditional.
>> 
>> We notice here that the rabbitmqadmin interface doesn't allow you to
>> conditionally delete. We have raised a bug to do this -- but in the meantime, I
>> would code a script that issues the rabbitmqadmin calls to determine which
>> queues to conditionally delete, and then invoke simple stand-alone client app to
>> do the conditional deletes.   It's a bit klunky, but reasonably safe.
>> 
>> Hope this helps.
>> Steve Powell  (a happy bunny)
>> ----------some more definitions from the SPD----------
>> vermin (v.) Treating the dachshund for roundworm.
>> chinchilla (n.) Cooling device for the lower jaw.
>> socialcast (n.) Someone to whom everyone is speaking but nobody likes.
>> 
>> On 22 Jan 2012, at 07:40, Yogesh Ketkar wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Thanks Steve and Simon.
>> 
>>> I checked that rabbitmqadmin.py uses http calls (RESTful APIs)
>>> provided by RabbitMQ to perform the operations.
>>> Can you provide me a sample
>>> - (either using rabbitmqadmin or using RESTful client) to delete a
>>> queue say "Yogesh" with isEmpty and isUnused flags set to True?
>>>  I could delete the queue using DELETE http request on
>>> http://localhost:55672/api/queues/%2f/Yogesh
>>>  But couldn't figure out a way to specify isEmpty and isUnused flags.
>>> - I was able to do this in a Java client using interface
>>> com.rabbitmq.client.Channel { queueDelete("Yogesh", true, true) }.
>>>  But then, how do I get list of queues using com.rabbitmq.client?
>> 
>>> regards, Yogesh
>> 
>>> On Jan 20, 7:25 pm, Steve Powell <st... at rabbitmq.com> wrote:
>>>> Just a thought,
>> 
>>>> If you go the way Simon says and have something from outside poking the mgmt API
>>>> every few minutes, make sure you issue queueDelete with the if-empty bit set.
>>>> There is a window between the poking and the deleting in which messages may
>>>> arrive on the queue (i.e. it's not idle anymore), and it may even not be in-use
>>>> (have consumers) by the time you get to it.
>> 
>>>> Steve Powell
>>>> st... at rabbitmq.com
>>>> [wrk:+44-2380-111-528begin_of_the_skype_highlighting            +44-2380-111-528      begin_of_the_skype_highlighting            +44-2380-111-528      ] [mob:+44-7815-838-558begin_of_the_skype_highlighting            +44-7815-838-558      begin_of_the_skype_highlighting            +44-7815-838-558      ]
>> 
>>>> On 20 Jan 2012, at 12:47, Simon MacMullen wrote:
>> 
>>>>> On 16/01/12 15:56, Yogesh Ketkar wrote:
>>>>>> I would like to delete the queue with no messages in it and so asked
>>>>>> the question.
>> 
>>>>> I see.
>> 
>>>>>> Can you suggest an alternative to achieve
>>>>>> 1. Delete the queue when last event processed from the queue has
>>>>>> <Action>Delete</Action>  as this implies that
>>>>>>    no more events with same<AppId>  would ever get created.
>> 
>>>>> Well, you could have your client do that.
>> 
>>>>>> 2. Delete the queue when it is IDLE for certain period, meaning it is
>>>>>> empty and no more event was added to it for certain time period.
>> 
>>>>> Hmm. Well there's nothing built in to do this, but you could have something from outside poking the mgmt API every few minutes - look at the output of (e.g.)
>> 
>>>>> rabbitmqadmin list queues name messages consumers idle_since
>> 
>>>>> Cheers, Simon
>> 
>>>>> --
>>>>> Simon MacMullen
>>>>> RabbitMQ, VMware
>>>>> _______________________________________________
>>>>> rabbitmq-discuss mailing list
>>>>> rabbitmq-disc... at lists.rabbitmq.com
>>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> 
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-disc... at lists.rabbitmq.com
>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>> 
>> 
>> 
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-disc... at lists.rabbitmq.comhttps://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discussTh
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120123/d4f7893d/attachment.htm>