[rabbitmq-discuss] BIGIP/F5 and Connection resets

Tue Dec 18 12:52:10 GMT 2012

Hi Jason,

On 17/12/12 22:53, Jason McIntosh wrote:

> From what I've been told, most network devices drop TCP/IP
> connections after an hour automatically (i.e. switches, routers,
> etc.) and force a reconnect - not sure if Rabbit handles this?

The broker handles a closed connection by logging the event.

> There is a work around at the moment we're looking into.  It looks like
> most (if not all) Rabbit interfaces have a heartbeat setting that would
> allow connections to be maintained

Yes, AMQP heartbeats are a suitable solution if intermediate network
devices are closing idle connections too eagerly. Heartbeats are enabled
by default in v3.0.0 if the client supports them.

Another options is to write client applications to re-establish closed
connections after a suitable delay.

If consumers receive messages asynchronously instead of polling the
broker for messages, and there are no messages to deliver then the TCP
connection will carry no traffic.

> Other questions related to the above:  Is the AMQP protocol designed to
> have the clients just sit idle, no communication with the servers until
> a message comes in

Rabbit does not impose limits on connection duration and idle
connections are permitted to remain so indefinitely.

> If there is no check, and the client hasn't received a message in a
> day at what point do you retry your connection to verify you're even
> still connected? It sounds like in this case you could have a
> consumer of a queue lose it's connection and never realize

If connections are being severed silently without notification from the
network stack then you must use AMQP heartbeats so that both sides of
the connection become aware of it. Otherwise the network stack should
provide notification that the connection has been interrupted.

> Then you'd have a server just sitting backlogging messages waiting
> for a client (or worse depending on configuration, just dropping all
> the messages).

The broker will not drop messages due to broken connections and the
protocol is designed so that a guarantee of message delivery can be
offered even in the face of an unreliable transport.

> Looked at the AMQP 0-9-1 specifications and not seeing a whole lot
> defined on how AMQP implementers are supposed to work with TCP/IP
> traffic (other than some heartbeat definitions).

The "connection" class relates to the transport, which must be
stream-oriented.

-Emile