Mailing-List: contact zookeeper-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: zookeeper-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns;
	h=from:to:references:subject:date:message-id:mime-version:
	content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index;
	b=02rT2+8dLnZ1CMXWu4asP84AwNhF/6T5O7o+7jpWCzA2MS6WlZBUZ2L5n/kq1zMN
From: "Flavio Junqueira	" <fpj@yahoo-inc.com>
To: <zookeeper-dev@hadoop.apache.org>
References: <ec6e67fd0807180706p7b85e05apa86bfdea5ff18cbd@mail.gmail.com>
Subject: RE: javadoc for the Write Lock / Leader Election
Date: Fri, 18 Jul 2008 16:40:21 +0200
Message-ID: <000a01c8e8e4$3547bae0$70060a0a@ds.corp.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <ec6e67fd0807180706p7b85e05apa86bfdea5ff18cbd@mail.gmail.com>
Thread-Index: Acjo35l1d7k55gYTQd+c0U5Q34CnMgAAGHEg

Hi James, the fact that the client's node has another node n ahead of it the
in the sequence order doesn't mean that the owner of n is aware that it is
the lock holder or the leader. This is because operations are propagated
asynchronously. Also, a getChildren() doesn't guarantee that you have the
latest list, and it is possible that another node is at the head of the
ordered list of nodes at the moment you read the response of getChildren().
This is because getChildren() will return the local state of one server,
while the ensemble of servers is processing or have even already decided
upon a change to the list. 

In the way I understand Jacob's suggestion, a leader client creates a
separate node to acknowledge that it is actually aware that it is the
leader, and so it is ready to perform the role of a leader. 

-Flavio

> -----Original Message-----
> 
> One thing confused me though; the last paragraph says...
> 
> This protocol guarantees that there is at any time only one node that
> thinks it is the leader. But it does not disseminate information about
> who is the leader. If you want everyone to know who is the leader, you
> can have an additional Znode whose value is the name of the current
> leader (or some identifying information on how to contact the leader,
> etc.). Note that this cannot be done atomically, so by the time other
> nodes find out who the leader is, the leadership may already have
> passed on to a different node.
> 
> In the current implementation, WriteLock - each znode can know,
> whenever it attempts to acquire the lock - if it didn't get the lock,
> who the owner is. I guess this is only true momentarily the split
> second that the acquire() method is called (i.e. the exact moment the
> getChildren() is called and the lowest value is found). Or is there
> some other subtle issue I'm not seeing?
> 
> I guess we could add a method to WriteLock - if folks wanted - a kinda
> queryLeader() method where we just use the same algorithm to find who
> the current leader is - if folks cared. Though am not sure how useful
> knowing who the leader is :). Though I guess writing the leader's
> identity to some canonical znode that any other znode can read
> whenever it wishes is less risky and maybe simpler.
> 
> --
> James
> -------
> http://macstrac.blogspot.com/
> 
> Open Source Integration
> http://open.iona.com