A switch failure could do that, I think.
On Fri, Sep 10, 2010 at 1:49 PM, Fournier, Camille F. [Tech] <
camille.fourn...@gs.com> wrote:
> I am not a networking expert, but in my experience I've seen network
> glitches that cause sockets to appear to be live that are actually dead, but
> not vice-
ber 10, 2010 4:02 PM
To: Fournier, Camille F. [Tech]
Cc: 'zookeeper-user@hadoop.apache.org'
Subject: Re: closing session on socket close vs waiting for timeout
the problem is that followers don't track session timeouts. they track
when they last heard from the sessions t
They would only get expired sessions if they don't reconnect to another
server within a relatively short timeout (at least according to my original
idea... I haven't looked at Camille's suggestion carefully enough to see if
she meant that).
As I see it, the server that loses the client should prop
From: Benjamin Reed [mailto:br...@yahoo-inc.com]
Sent: Wednesday, September 08, 2010 4:03 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: closing session on socket close vs waiting for timeout
unfortunately, that only works on the standalone server.
ben
On 09/08/2010 12:52 PM, Fournier, Camille F
010 1:11 PM
To: zookeeper-user@hadoop.apache.org
Cc: Benjamin Reed
Subject: Re: closing session on socket close vs waiting for timeout
This really is, just as Ben says a problem of false positives and false
negatives in detecting session
expiration.
On the other hand, the current algorithm isn'
riginal Message-
From: Benjamin Reed [mailto:br...@yahoo-inc.com]
Sent: Wednesday, September 08, 2010 4:03 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: closing session on socket close vs waiting for timeout
unfortunately, that only works on the standalone server.
ben
On 09/08/2010 12
here.
Thanks,
C
-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com]
Sent: Wednesday, September 08, 2010 4:51 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: closing session on socket close vs waiting for timeout
To get it to work in a cluster, what would be necessar
l 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
>>&g
@hadoop.apache.org
Cc: Benjamin Reed
Subject: Re: closing session on socket close vs waiting for timeout
This really is, just as Ben says a problem of false positives and false
negatives in detecting session
expiration.
On the other hand, the current algorithm isn't really using all the
information avai
actual code in this email)
-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com]
Sent: Tuesday, September 07, 2010 1:11 PM
To: zookeeper-user@hadoop.apache.org
Cc: Benjamin Reed
Subject: Re: closing session on socket close vs waiting for timeout
This really is, just as Ben
t;> 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
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
>&g
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 so
Wednesday, September 01, 2010 3:47
PM To: zookeeper-user@hadoop.apache.org Cc: Benjamin Reed Subject:
Re: closing session on socket close vs waiting for timeout
Ben, in this case the session would be tied directly to the
connection, we'd explicitly deny session re-establishment for this
se
lto:ph...@apache.org]
Sent: Wednesday, September 01, 2010 3:47 PM
To: zookeeper-user@hadoop.apache.org
Cc: Benjamin Reed
Subject: Re: closing session on socket close vs waiting for timeout
Ben, in this case the session would be tied directly to the connection,
we'd explicitly deny session
op.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 reco
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, whic
s,
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 cr
That's what I read too...
Sounds like having a session type that's bound to the connection lifetime
would be useful. We might want to have an option to turn off ZK heartbeating
and use tcp keep alive for those session types.
Patrick
On Tue, Aug 31, 2010 at 10:14 AM, Dave Wright wrote:
> I thin
That's what I read too...
Sounds like having a session type that's bound to the connection lifetime
would be useful. We might want to have an option to turn off ZK heartbeating
and use tcp keep alive for those session types.
Patrick
On Tue, Aug 31, 2010 at 10:14 AM, Dave Wright wrote:
> I thin
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
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
All,
I'm working on a ZK deployment that will support a heterogeneous set of
processes connecting to the ZK and creating ephemeral nodes. We have the
conflicting requirements that:
a) If a process crashes (closes its socket) without calling a proper
close, we would like the ephemeral node
23 matches
Mail list logo
