Bunny doesn't heartbeat

[marcbowes]

There are no threads and no calls to send_heartbeat. Correct me if I'm wrong, but this means that enabling heartbeats will likely cause clients to drop more often than without it, especially if you're in a long running subscribe block. This seems like really common behavior to me (wanting to subscribe to a queue) and it seems silly to push the responsibility of responding to heartbeats down to consumers of this library.

[michaelklishin]

Heartbeats in AMQP 0.9.1 are optional. Do you want to help implementing this functionality?

[marcbowes]

Here is my use-case:

I have a simple worker that pulls work from a queue, acts on it and then moves onto the next item. I do this using a subscribe block. The code is neat, easy to follow and highly testable.

The problem is that when the underlying connection dies, I don't know about it until the subscribe block hits its timeout. At that point it cancels the subscription, which triggers an exception because the network connection is dead. Worst case here is a 15 min period where the worker is doing nothing.

Heartbeats seemed exactly what I wanted. Is there another way?

[michaelklishin]

You can either implement heartbeat support or have a thread that publishes messages that won't be routed anywhere (using default exchange and a random string as routing key). At least RabbitMQ should treat connection activity as heartbeats, regardless of what the client specified as heartbeat interval.

[marcbowes]

Please leave this issue open. At the very least it'll answer somebody else's question on the matter. At the best, it might attract a pull request.

[michaelklishin]

Will be solved after a rewrite