[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