Why can't an ephemeral non sequential node creation be used as a lock?

[ka...@gmail.com]

Hi,

I have 3 zookeeper clients that will receive a request within seconds apart.  Only 1 client is allowed to handle this request.

I was thinking that each client will try to create the same ephemeral node non sequential node. The client that can is by definition the leader and is the one that will handle the request.

But then I saw that there's a recipe for creating a lock. 

Would the above strategy work or should I use the recipe? Can someone tell me what could go wrong with what I described?

Thanks 

Re: Why can't an ephemeral non sequential node creation be used as a lock?

[Chris Nauroth <cn...@hortonworks.com>]

Yes, agreed.  My response raced with Flavio's.  That also gives you a sort
of real-world demo of the thundering herd effect.  :-)

--Chris Nauroth




On 11/3/15, 10:38 AM, "Flavio Junqueira" <fp...@apache.org> wrote:

>There is nothing wrong with what you described. The one undesirable
>effect of doing the way you describe is that all clients watching will
>wake when the ephemeral is deleted. Assuming the recipe you're talking
>about is the one that chains watches, it avoids waking up all clients
>when the ephemeral is deleted.
>
>-Flavio
>
>
>> On 03 Nov 2015, at 18:30, kamel.zaarouri@gmail.com wrote:
>> 
>> Hi,
>> 
>> I have 3 zookeeper clients that will receive a request within seconds
>>apart.  Only 1 client is allowed to handle this request.
>> 
>> I was thinking that each client will try to create the same ephemeral
>>node non sequential node. The client that can is by definition the
>>leader and is the one that will handle the request.
>> 
>> But then I saw that there's a recipe for creating a lock.
>> 
>> Would the above strategy work or should I use the recipe? Can someone
>>tell me what could go wrong with what I described?
>> 
>> Thanks
>
>

Re: Why can't an ephemeral non sequential node creation be used as a lock?

[Flavio Junqueira <fp...@apache.org>]

There is nothing wrong with what you described. The one undesirable effect of doing the way you describe is that all clients watching will wake when the ephemeral is deleted. Assuming the recipe you're talking about is the one that chains watches, it avoids waking up all clients when the ephemeral is deleted.

-Flavio


> On 03 Nov 2015, at 18:30, kamel.zaarouri@gmail.com wrote:
> 
> Hi,
> 
> I have 3 zookeeper clients that will receive a request within seconds apart.  Only 1 client is allowed to handle this request.
> 
> I was thinking that each client will try to create the same ephemeral node non sequential node. The client that can is by definition the leader and is the one that will handle the request.
> 
> But then I saw that there's a recipe for creating a lock. 
> 
> Would the above strategy work or should I use the recipe? Can someone tell me what could go wrong with what I described?
> 
> Thanks

Re: Why can't an ephemeral non sequential node creation be used as a lock?

[Chris Nauroth <cn...@hortonworks.com>]

Hi Kamel,

The implementation you described (ephemeral but not sequential) can be
prone to the thundering herd effect [1].  One client will obtain the lock,
and the other 2 will need to call exists to set a watch on the lock znode
created by that client.  This is important to detect if the client holding
the lock releases that lock (either intentionally or unintentionally due
to process death), so that another one of the client processes can acquire
the lock and make progress.  Since all clients set a watch on that same
znode, all clients will wake up and try to acquire the lock again by
recreating that znode, but only one can succeed.

The standard recipe (ephemeral and sequential) does not suffer from the
thundering herd effect.  This is because each sequential znode is only
watched by a single other client, so the release of the lock (deletion of
the znode) only wakes up a single other client.  More details on this are
discussed in the recipe documentation [2].

This problem is somewhat analogous to Object#notify [3] vs.
Object#notifyAll [4] in concurrent Java programming.

This might not be a big deal with only 3 clients.  With a large number of
clients contending on the lock, the thundering herd effect can generate a
lot of wasteful extra work.

I hope this helps.

[1] https://en.wikipedia.org/wiki/Thundering_herd_problem
[2] http://zookeeper.apache.org/doc/r3.4.6/recipes.html#sc_recipes_Locks
[3] http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#notify()
[4] 
http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#notifyAll()

--Chris Nauroth




On 11/3/15, 10:30 AM, "kamel.zaarouri@gmail.com"
<ka...@gmail.com> wrote:

>Hi,
>
>I have 3 zookeeper clients that will receive a request within seconds
>apart.  Only 1 client is allowed to handle this request.
>
>I was thinking that each client will try to create the same ephemeral
>node non sequential node. The client that can is by definition the leader
>and is the one that will handle the request.
>
>But then I saw that there's a recipe for creating a lock.
>
>Would the above strategy work or should I use the recipe? Can someone
>tell me what could go wrong with what I described?
>
>Thanks