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

Tim Watson watson.timothy at gmail.com
Tue May 7 08:32:38 BST 2013


No problem - if you need to alleviate this then AMQP heartbeats can ensure client and broker notice a downed peer in a more timely fashion.

Cheers,
Tim

On 7 May 2013, at 08:04, carlhoerberg <carl.hoerberg at gmail.com> wrote:

> Ok, yes, suspected it had with to do with the underlaying TCP stack, thank you for the detailed explanation! 
> 
> 
> 
> On Tuesday 7 May 2013 at 14:58, Tim Watson-6 [via RabbitMQ] wrote: 
> 
> > Hi, 
> > 
> > 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. 
> > 
> > Cheers, 
> > Tim 
> > _______________________________________________ 
> > rabbitmq-discuss mailing list 
> > [hidden email] (/user/SendEmail.jtp?type=node&node=26470&i=0) 
> > https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
> > 
> > 
> > If you reply to this email, your message will be added to the discussion below: http://rabbitmq.1065348.n5.nabble.com/Java-client-closed-connection-doesn-t-raise-exception-immediately-tp26465p26470.html  
> > To unsubscribe from Java client: closed connection doesn't raise exception immediately, click here ( 
> > NAML (http://rabbitmq.1065348.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml)
> 
> 
> 
> 
> View this message in context: Re: Java client: closed connection doesn't raise exception immediately
> Sent from the RabbitMQ mailing list archive at Nabble.com.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130507/f21318a8/attachment.htm>


More information about the rabbitmq-discuss mailing list