[rabbitmq-discuss] Cleaning up temp-queues in long-running processes

Wed Dec 7 23:44:03 GMT 2011

On 08/12/11 02:07, Steve Powell wrote:
> Toby,
> I guess this a STOMP question again. Please correct me if I'm wrong.

It's STOMP, yes.
I explored using AMQP from Perl, but the only libraries available all 
had issues of one sort or another :(

> I assume you are using /temp-queue/<name>  destinations on the reply-to header
> on a SEND frame.

Correct.

> You are correct in that a temporary reply-to queue is created 'auto-delete'
> with an automatic (hidden) subscription; so the queue will be retained until
> the end of the session:  there is no way to remove that subscription (but
> see below).

OK, thanks for clarifying that.

> However, the bug that you cannot re-use the reply-to queue is now fixed and
> will be in the upcoming release.

Thanks, I'll look forward to it.

Thanks again for your help,
Toby

> We also have a bug 'on the books' that will expose the 'id' of the
> hidden subscription, in case the user wishes to UNSUBSCRIBE from it.  I'm
> not certain when this will be fixed, however.  Since its main use would be
> to work-around the other problem it is not guaranteed to be in the next release.
>
> Steve Powell  (a happy bunny)
> ----------some more definitions from the SPD----------
> avoirdupois (phr.) 'Would you like peas with that?'
> distribute (v.) To denigrate an award ceremony.
> definite (phr.) 'It's hard of hearing, I think.'
> modest (n.) The most mod.
>
> On 7 Dec 2011, at 00:10, Toby Corkindale wrote:
>
>> If I use the /temp-queue/ methods to create temporary queues, I see that
>> they remain in existence until the process disconnects from the RMQ broker.
>>
>> If you're using these for RPC on a long-running process, you soon have
>> huge numbers of queues on the broker.
>>
>> Is there a way to remove them once you're done?
>>
>> I tried UNSUBSCRIBE on them, but that didn't seem to work. (I don't have
>> a subscription id)
>>
>> The problem is compounded by the bug with re-using the temp-queues. Because
>> you need to use a unique name each time, every RPC call has to create a new
>> temp queue, rather than being able to reuse the same call for at least the
>> same methods.

-- 
.signature