when does an AMQP/RabbitMQ channel with no connections die?

Question

I have a simple RabbitMQ test program randomly enqueuing messages, and another reading them, all using Spring-AMQP. If the consumer dies (for example killing a process without having a chance to close its connection or channel), any messages that it had not acknowledged appear to remain unacknowledged forever.

I have seen a number of references (for example this question) that say that the channel dies when it has no connections, and that remaining unack'd messages will be redelivered. That's not the behaviour I see - instead I get a growing list of channels marked IDLE and a growing list of connections marked running but with no activity.

Is there some configuration required to notice that connections are dead once the process has been killed?

EDIT: I was running the rabbitmq server inside a VirtualBox VM, which apparently doesn't manage dead inbound connections correctly over NAT. This works just fine with the mq server running directly on the physical host.

Answer 1

Answering to close. This turns out not to be a real issue.

I was running the rabbitmq server inside a VirtualBox VM, which apparently doesn't manage dead inbound connections correctly over NAT. This works just fine with the mq server running directly on the physical host.

Answer 2

AMQP uses Queues and Exchanges. You publish on an exchange and you bind queues to get messages from exchanges (you can see a short explanation on my blog. When you create a queue you can set it to auto-delete as well as how much time will it stay unused before it auto deletes. Here's a quote from the RabbitMQ quickref:

queue.declare(short reserved-1, queue-name queue, bit passive, bit durable, bit exclusive, bit auto-delete, no-wait no-wait, table arguments) ➔ declare-ok

Support: full Declare queue, create if needed.

This method creates or checks a queue. When creating a new queue the client can specify various properties that control the durability of the queue and its contents, and the level of sharing for the queue.

RabbitMQ implements extensions to the AMQP specification that permits the creator of a queue to control various aspects of its behaviour.

Per-Queue Message TTL This extension determines for how long a message published to a queue can live before it is discarded by the server. The time-to-live is configured with the x-message-ttl argument to the arguments parameter of this method.

Queue Expiry Queues can be declared with an optional lease time. The lease time determines how long a queue can remain unused before it is automatically deleted by the server. The lease time is provided as an x-expires argument in the arguments parameter to this method.

Mirrored Queues We have developed active/active high availability for queues. This works by allowing queues to be mirrored on other nodes within a RabbitMQ cluster. The result is that should one node of a cluster fail, the queue can automatically switch to one of the mirrors and continue to operate, with no unavailability of service. To create a mirrored queue, you provide an x-ha-policy argument in the arguments parameter to this method.