i'm a bit skeptical that this is going to work out properly. a server
may receive a socket reset even though the client is still alive:
1) client sends a request to a server
2) client is partitioned from the server
3) server starts trying to send response
4) client reconnects to a different server
5) partition heals
6) server gets a reset from client
at step 6 i don't think you want to delete the ephemeral nodes.
ben
On 08/31/2010 01:41 PM, Fournier, Camille F. [Tech] wrote:
Yes that's right. Which network issues can cause the socket to close without
the initiating process closing the socket? In my limited experience in this
area network issues were more prone to leave dead sockets open rather than vice
versa so I don't know what to look out for.
Thanks,
Camille
-----Original Message-----
From: Dave Wright [mailto:wrig...@gmail.com]
Sent: Tuesday, August 31, 2010 1:14 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: closing session on socket close vs waiting for timeout
I think he's saying that if the socket closes because of a crash (i.e. not a
normal zookeeper close request) then the session stays alive until the
session timeout, which is of course true since ZK allows reconnection and
resumption of the session in case of disconnect due to network issues.
-Dave Wright
On Tue, Aug 31, 2010 at 1:03 PM, Ted Dunning<ted.dunn...@gmail.com> wrote:
That doesn't sound right to me.
Is there a Zookeeper expert in the house?
On Tue, Aug 31, 2010 at 8:58 AM, Fournier, Camille F. [Tech]<
camille.fourn...@gs.com> wrote:
I foolishly did not investigate the ZK code closely enough and it seems
that closing the socket still waits for the session timeout to remove the
session.
