Network partition and ephemeral nodes

[Narayanan Arunachalam <na...@gmail.com>]

Hi,

In case the network between ZK cluster and client is partitioned, once the session expires would it remove the ephemeral nodes? If that's the case how is the correctness of the recipes like locks are archived. Because once the ephemeral nodes are removed next client would be granted the lock isn't it.

Regards,
Nara

Re: Network partition and ephemeral nodes

[Ted Dunning <te...@gmail.com>]

Any single ZK operation will throw an error if a disconnect from the quorum
is detected during an operation.  The way that you would normally see this
in the middle of a fast sequence of operations is as an exception from one
of the operations you are trying to do.

On Sun, Nov 25, 2012 at 12:14 PM, Narayanan Arunachalam <
narayanan.arunachalam@gmail.com> wrote:

> In that case, a client using the lock recipe for instance, should keep an
> eye on disconnect event and abort the operation it started (the operation
> to be only run in the critical section), since there is no guarantee that
> it has the lock any more.
>
> On Nov 25, 2012, at 11:40 AM, Ted Dunning <te...@gmail.com> wrote:
>
> > To expand on this, when a client is disconnected, it receives a
> disconnect
> > event.
> >
> > From that time until the client is reconnected, the client doesn't know
> > what has happened.  The session may have expired or it may have not
> > expired.  Keep in mind that clock changes can make reasoning during this
> > time impossible to do with precision.
> >
> > What the client does during this period of ignorance is up to the
> designer
> > of the application.  There are several potential strategies.  If the
> > application must have at most one master, then the disconnected client
> > should immediately stop behaving as a master.  If the application must
> have
> > at least one master, then the disconnected client should continue as
> > master.  If you have an in between strategy where it is bad but not fatal
> > to have two masters, you can have the disconnected client behave as a
> > master up to the point where it thinks that it likely has been superseded
> > by some other method.
> >
> > Zookeeper cannot decide this issue for you.
> >
> > On Sun, Nov 25, 2012 at 10:49 AM, Camille Fournier <camille@apache.org
> >wrote:
> >
> >> Yes if quorum is intact but the client cannot connect to the zookeeper,
> the
> >> session and the ephemeral nodes will expire. It is up to users of ZK for
> >> locking to correctly assume that a given client is not the lock holder
> if
> >> its connection to the ZooKeeper is lost.
> >>
> >> C
> >>
> >> On Sun, Nov 25, 2012 at 1:32 PM, Narayanan Arunachalam <
> >> narayanan.arunachalam@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> In case the network between ZK cluster and client is partitioned, once
> >> the
> >>> session expires would it remove the ephemeral nodes? If that's the case
> >> how
> >>> is the correctness of the recipes like locks are archived. Because once
> >> the
> >>> ephemeral nodes are removed next client would be granted the lock isn't
> >> it.
> >>>
> >>> Regards,
> >>> Nara
> >>
>

Re: Network partition and ephemeral nodes

[Narayanan Arunachalam <na...@gmail.com>]

In that case, a client using the lock recipe for instance, should keep an eye on disconnect event and abort the operation it started (the operation to be only run in the critical section), since there is no guarantee that it has the lock any more.

On Nov 25, 2012, at 11:40 AM, Ted Dunning <te...@gmail.com> wrote:

> To expand on this, when a client is disconnected, it receives a disconnect
> event.
> 
> From that time until the client is reconnected, the client doesn't know
> what has happened.  The session may have expired or it may have not
> expired.  Keep in mind that clock changes can make reasoning during this
> time impossible to do with precision.
> 
> What the client does during this period of ignorance is up to the designer
> of the application.  There are several potential strategies.  If the
> application must have at most one master, then the disconnected client
> should immediately stop behaving as a master.  If the application must have
> at least one master, then the disconnected client should continue as
> master.  If you have an in between strategy where it is bad but not fatal
> to have two masters, you can have the disconnected client behave as a
> master up to the point where it thinks that it likely has been superseded
> by some other method.
> 
> Zookeeper cannot decide this issue for you.
> 
> On Sun, Nov 25, 2012 at 10:49 AM, Camille Fournier <ca...@apache.org>wrote:
> 
>> Yes if quorum is intact but the client cannot connect to the zookeeper, the
>> session and the ephemeral nodes will expire. It is up to users of ZK for
>> locking to correctly assume that a given client is not the lock holder if
>> its connection to the ZooKeeper is lost.
>> 
>> C
>> 
>> On Sun, Nov 25, 2012 at 1:32 PM, Narayanan Arunachalam <
>> narayanan.arunachalam@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> In case the network between ZK cluster and client is partitioned, once
>> the
>>> session expires would it remove the ephemeral nodes? If that's the case
>> how
>>> is the correctness of the recipes like locks are archived. Because once
>> the
>>> ephemeral nodes are removed next client would be granted the lock isn't
>> it.
>>> 
>>> Regards,
>>> Nara
>> 

Re: Network partition and ephemeral nodes

[Ted Dunning <te...@gmail.com>]

To expand on this, when a client is disconnected, it receives a disconnect
event.

>From that time until the client is reconnected, the client doesn't know
what has happened.  The session may have expired or it may have not
expired.  Keep in mind that clock changes can make reasoning during this
time impossible to do with precision.

What the client does during this period of ignorance is up to the designer
of the application.  There are several potential strategies.  If the
application must have at most one master, then the disconnected client
should immediately stop behaving as a master.  If the application must have
at least one master, then the disconnected client should continue as
master.  If you have an in between strategy where it is bad but not fatal
to have two masters, you can have the disconnected client behave as a
master up to the point where it thinks that it likely has been superseded
by some other method.

Zookeeper cannot decide this issue for you.

On Sun, Nov 25, 2012 at 10:49 AM, Camille Fournier <ca...@apache.org>wrote:

> Yes if quorum is intact but the client cannot connect to the zookeeper, the
> session and the ephemeral nodes will expire. It is up to users of ZK for
> locking to correctly assume that a given client is not the lock holder if
> its connection to the ZooKeeper is lost.
>
> C
>
> On Sun, Nov 25, 2012 at 1:32 PM, Narayanan Arunachalam <
> narayanan.arunachalam@gmail.com> wrote:
>
> > Hi,
> >
> > In case the network between ZK cluster and client is partitioned, once
> the
> > session expires would it remove the ephemeral nodes? If that's the case
> how
> > is the correctness of the recipes like locks are archived. Because once
> the
> > ephemeral nodes are removed next client would be granted the lock isn't
> it.
> >
> > Regards,
> > Nara
>

Re: Network partition and ephemeral nodes

[Camille Fournier <ca...@apache.org>]

Yes if quorum is intact but the client cannot connect to the zookeeper, the
session and the ephemeral nodes will expire. It is up to users of ZK for
locking to correctly assume that a given client is not the lock holder if
its connection to the ZooKeeper is lost.

C

On Sun, Nov 25, 2012 at 1:32 PM, Narayanan Arunachalam <
narayanan.arunachalam@gmail.com> wrote:

> Hi,
>
> In case the network between ZK cluster and client is partitioned, once the
> session expires would it remove the ephemeral nodes? If that's the case how
> is the correctness of the recipes like locks are archived. Because once the
> ephemeral nodes are removed next client would be granted the lock isn't it.
>
> Regards,
> Nara