9

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.

Community
  • 1
  • 1
Joe Kearney
  • 7,397
  • 6
  • 34
  • 45
  • 1
    FYI: I was having a similar problem where exclusive queues were not being cleaned up on the broker in a timely manner after the exclusive consumer dies. This prevented these components with deterministic names from starting. It was solved by setting `ConnectionFactory.RequestedHeartbeat` to a small value (seconds) – drstevens Dec 09 '11 at 21:32

2 Answers2

4

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.

Brian Kelly
  • 19,067
  • 4
  • 53
  • 55
Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68
  • I don't want the queue to be deleted, I want it to be persistent. But I also want the unacknowledged messages (consumed by processes that died before acknowledging) to be redelivered. It's the dead connections/channels that need deleting, not messages. – Joe Kearney Nov 29 '11 at 08:36
  • 2
    ok now I got you - you need to create ConnectionParameters instance and set a heartbeat (setRequestedHeardbeat) to a reasonable value (1 heartbeat miss will close the channel) Then pass that to the ConnectionFactory constructor – Arnon Rotem-Gal-Oz Nov 29 '11 at 21:15
  • @Arnon Rotem-Gal-Oz, setting `RequestedHeartbeat` solved my similar problem which was manifesting by exclusive queues not being cleaned up on the broker in a timely manner. This prevented components which declare exclusive queues with deterministic names from starting. – drstevens Dec 09 '11 at 21:30
  • @drstevens right- that's pretty much the same issue. The broker needs to know that clients are gone to release resources – Arnon Rotem-Gal-Oz Dec 09 '11 at 21:43
3

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.

Joe Kearney
  • 7,397
  • 6
  • 34
  • 45