Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Subject: Re: Why can't an ephemeral non sequential node creation be used as
 a lock?
MIME-Version: 1.0
From: Chris Nauroth <cnauroth@hortonworks.com>
To: "user@zookeeper.apache.org" <user@zookeeper.apache.org>,
	"zookeeper-user@hadoop.apache.org" <zookeeper-user@hadoop.apache.org>
Thread-Topic: Why can't an ephemeral non sequential node creation be used as a
 lock?
Thread-Index: AQHRFmWwyB5GWB2bJ0mv08zilksiuZ6KkegA
Date: Tue, 3 Nov 2015 18:44:59 +0000
Message-ID: <D25E3EA7.31894%cnauroth@hortonworks.com>
References: <732D3AF1-0E42-452B-AABE-6FEA9F63B2F0@gmail.com>
In-Reply-To: <732D3AF1-0E42-452B-AABE-6FEA9F63B2F0@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <706C3372D58EED41996C7BDE10FB04A9@exch080.serverpod.net>
Content-Transfer-Encoding: quoted-printable

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]=20
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"
<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=20