Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [milo-dev] Detecting connection loss

Mads - what we do to kick the state machine into reconnect mode is this:

client.getStackClient().getChannelFuture()
.thenApply(sc -> sc.getChannel().close());
If you were to simply call client.disconnect() your subscriptions would get trashed. This method tricks the state machine into acting the same way it would when the broken channel was finally detected. Your subscription state is left unchanged, and at worst you'll have to deal with the callback that notifies you your subscriptions couldn't be transferred.

Phil - what I guess I really meant is I've observed Java to behave differently on different OS's with regards to TCP keep-alive. Even then, I think it's best practice for people to pretend it doesn't exist or doesn't work, because it's optional anyway...


On Wed, May 2, 2018 at 7:31 AM, Phil Turmel <philip@xxxxxxxxxx> wrote:
It's not really an OS question... it's built into the specification for
TCP/IP -- the time-wait state that cuts off a broken connection can
persist for up to four minutes in older products following the original
RFC.  IIRC, the latest RFCs for TCP/IP shorten it to 90 seconds.

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

On 05/02/2018 09:37 AM, Mads Stavang wrote:
> Thanks for your prompt reply Kevin. Yes, the detection of cable pulling
> (or loose contact, defective cable, power outtake of device etc.) is the
> issue which causes the most problems on our TCP/IP connections, because
> they are the hardest to detect. I will do the periodic requests as
> suggested.
>
> On 2 May 2018 at 14:04, Kevin Herron <kevinherron@xxxxxxxxx
> <mailto:kevinherron@xxxxxxxxx>> wrote:
>
>     Mads,
>
>     Unfortunately, the way TCP Keep-Alive works (or doesn't work...)
>     means that pulling the ethernet cable anywhere in the route between
>     client and server is often a pathological worst case. You're
>     essentially at the mercy of the OS to decide the connection has been
>     lost and report it.
_______________________________________________
milo-dev mailing list
milo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/milo-dev


Back to the top