[rabbitmq-discuss] Java client: closed connection doesn't raise exception immediately

Tim Watson tim at rabbitmq.com
Tue May 7 07:55:48 BST 2013


On 7 May 2013, at 04:32, carlhoerberg wrote:

> It looks like the rabbitmq java client doesn't raise an exception as soon as
> a connection fails, eg. due to network cable disconnection. 
> The following code will continue to run for 2 minutes after the
> disconnection, and first then raise an exception. 

That's perfectly normal, for a network driven application. It is not RabbitMQ's client library that wait's to throw an exception, but rather it is the operating system's network stack that takes time to determine that a peer socket is no longer available. This can take many minutes, even when you're connecting via the loopback interface (i.e., localhost) for testing.

On most unices, the relevant bits of `man tcp` are:

    "When  a  network  error  occurs, TCP tries to resend the packet.  If it
     doesn't succeed after some time, either ETIMEDOUT or the last received
     error on this connection is reported."

In that second sentence, "after some time" is determined by the OS kernel configured limits, viz tcp_retries1 (defaults to 3 on linux) and tcp_retries2, and the configured retransmission timeout. Of course there are doubtless other parameters that interact with this behaviour. So you're quite lucky because it's a producer application that's trying to send - those time out much faster. For network consumer applications, this problem is quite a tricky on because the default settings on linux for example, mean delays of between 10 and 30 minutes before the OS networking layer "notices" the connection has timed out.

This problem is, of course, not specific to RabbitMQ.


More information about the rabbitmq-discuss mailing list