[rabbitmq-discuss] Heartbeat vs timeout in .NET code

[Michael Klishin]

On 14 April 2014 at 23:28:43, Arun Rao (arunrao.seattle at gmail.com) wrote:
> > Sorry guys for extending this topic further and further. What  
> if I disabled heartbeat?

Then you get “regular” TCP connection loss detection, which is quite
slow (TCP tries to redeliver first).

> On the producer side - When a producer tries to send a message,  
> .NET client code will catch Connection Shutdown exception and  
> try to reinitiate the connection. Depending on the traffic on  
> the connection, this could be caught within a second if the connection  
> was active sending data or within several minutes if the connection  
> was idle.

If the peer is unreachable and did not close TCP connection, then no,
it can take well more than a second, depending on TCP stack configuration.


> On the consumer side - How frequently does the consumer check  
> the queue for messages? 

Consumers that use basic.consume *never* check for messages. Messages are sent
to them by RabbitMQ.

> I thought that even without heartbeats  
> Consumers will catch the following exception:
>  
> System.IO.IOException: Unable to read data from the transport  
> connection: An existing connection was forcibly closed by the  
> remote host. ---> System.Net.Sockets.SocketException: An  
> existing connection was forcibly closed by the remote host

This sounds like an exception after a connection was closed via RabbitMQ
management plugin. This involves closing TCP connection properly, so
the socket is immediately “marked" as closed by the OS. In this scenario,
it’s all good.

When either peer becomes unreachable, however, it can take a while (up to multiple minutes
is not unheard of) to detect. This is why heartbeats were introduced in the protocol. 
--  
MK  

Software Engineer, Pivotal/RabbitMQ