[rabbitmq-discuss] STOMP and anonymous queue deletions

Thu Feb 19 11:09:13 GMT 2009

Matthias Radestock wrote:
> Also note that auto_delete is the default.

... which means that the system somehow considers the channel on which 
the queue was declared to still be open. Matthias' suggestion about 
running netstat is good one.

However, it could well be something else. Looking at the output of 
list_queues, the consumer count is shown as zero, at the same time as 
auto_delete is shown as true, which is very strange. We don't collect 
information on whether a queue ever had a consumer as part of the 
list_queues output, unfortunately.

Does the number of garbage queues exactly match the number of 
connections, or is it much smaller? If it's close to the number of 
connections, there may be something systematic going on, which gives us 
a good chance of reproducing it; but if it's much smaller, it's possible 
that something is happening between the queue declaration and the 
basic.consume that the STOMP gateway does on the client's behalf.

If possible, please put a trace on one of the zombie queues (run 
appmon:start() and use the "trace" button in the view for rabbit), and 
then in another window run "rabbitmqctl list_queues". This will result 
in output similar to the following in the shell in which you started appmon:

*DBG* <0.164.0> got call {info,[name,messages]} from <0.169.0>
*DBG* <0.164.0> sent {ok,[{name,{resource,<<"/">>,queue,<<"foo">>}},
                           {messages,0}]} to <0.169.0>, new state 
{q,{amqqueue,{resource,<<47>>,queue,<<102,111,111>>},false,true,[],none},none,none,true,1,{[],[]},{[{<0.163.0>,{consumer,<<81,95,102,111,111>>,false}}],[]}}
*DBG* <0.164.0> got timeout

The piece of the output that we are interested in is the "{q,{...}}" 
part. Where my output says "true" in the fourth entry after the initial 
"q", yours may say "false", and if it does, that indicates that 
something went wrong between queue declaration and basic.consume.

Regards,
   Tony