[rabbitmq-discuss] Message unacked, Queue not responding...

[Tim Watson]

Hi 

On 21 Nov 2012, at 08:36, jhiemer wrote:

> Good Morning guys, 
> I have a question regarding queues with Rounting Key. It set the queues up, and the first two hours it runs very well. After a few hours of runtime the messages get into the queue, get the Unacked tag, but nothing happens. Even if I remove the consumer the messages are still in the Unacked state. First when I restart both, RabbitMQ Server as well as the consumer, or close the consumer and wait for 15 (?) minute, it works again. It seems that this is an issue with the timeout period or something?
> 
> 
> I would be very glad if someone could help me out.

I'd be happy to try and help, but I must admit that I'm very confused about what you're saying. From what I can gather, you've got some queues and some exchanges bound to them and you're sending messages with routing keys and everything is good. Some time later, you're finding that messages have arrived in the queue and are in an unacked state - presumably you've seen this by running `rabbitmqctl messages_unacknowledged` or used the management plugin. 

> Even if I remove the consumer the messages are still in the Unacked state.

Removing a consumer is not going to help - you need to consume and then ACK the messages, otherwise they'll remain un-acked forever. From http://www.rabbitmq.com/tutorials/tutorial-two-python.html we can read:

<quote>
It's a common mistake to miss the basic_ack. It's an easy error, but the consequences are serious. Messages will be redelivered when your client quits (which may look like random redelivery), but RabbitMQ will eat more and more memory as it won't be able to release any unacked messages. 
</quote>

> First when I restart both, RabbitMQ Server as well as the consumer, or close the consumer and wait for 15 (?) minute, it works 
> again. It seems that this is an issue with the timeout period or something?


It really is totally unclear what you're doing here. The responsibility for acknowledgements lies with the consumer, so it seems likely to me that your consumer code is forgetting to ACK for some reason or another. If this is not the case, and you are seeing that the consumer sends a basic.ack but the messages are not being removed from the queue, then please send a minimal test case demonstrating this. I very much doubt that is what's happening.

If you've set up per-queue or per-message (in 3.0) TTL and you've got DLX configurations then it's possible that the configuration is wrong somehow but again I'm finding it hard to visualise how this scenario would crop up even then. What kind of queue are we talking about; Is this a durable queue? Have you enabled per-queue-ttl for this queue? Is there a deal letter exchange set up for it? 

If you can provide a bit more information about what your setup looks like and what exactly your clients are doing (i.e., basic.consume and basic.ack for each message, etc) then we should be able to get this sorted out for you!

Tim