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

[Steve Powell]

Toby,
I guess this a STOMP question again. Please correct me if I'm wrong.

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

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).

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

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.