Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of mutsuzaki@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Reply-To: michi@cs.stanford.edu
Sender: mutsuzaki@gmail.com
In-Reply-To: 
 <CAMXp9VucX0DDms6sx4vAnq_yTWvzQ0KAfc+KERrx2+rkqft6LA@mail.gmail.com>
References: 
 <CAMvtm0fAnLaWuZw209pUPYN1JyrbjK9Sd2wr9cSnn_+L-n1Qew@mail.gmail.com>
	<CAMXp9VucX0DDms6sx4vAnq_yTWvzQ0KAfc+KERrx2+rkqft6LA@mail.gmail.com>
Date: Mon, 10 Sep 2012 18:45:11 -0700
Message-ID: 
 <CAHYqJpHZU8W=9ZBJprHhAyCdfUeTkvoJjWyAiD4qUa_jjsVLHA@mail.gmail.com>
Subject: Re: Error in zookeeper recipes documention of " Leader Election"
From: Michi Mutsuzaki <michi@cs.stanford.edu>
To: user@zookeeper.apache.org
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: quoted-printable

Yeah this has been a known issue for a while. I'll create a patch for it.

https://issues.apache.org/jira/browse/ZOOKEEPER-1483

--Michi

On Mon, Sep 10, 2012 at 6:26 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> Yes, I mentioned this over a year and a half ago: -
> http://zookeeper-user.578899.n2.nabble.com/leader-election-td6086870.html=
 -
> looks like it still hasn't been rectified.
>
> Ishaaq
>
> On 11 September 2012 11:13, nileader <nileader@gmail.com> wrote:
>
>> Hi,all
>>
>>    About =A1=A7Leader Election=A1=A8part of zookeeper recipes documentio=
n(
>> http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection),ma=
ny
>> of my colleagues are confused on this: "Otherwise, watch for changes on
>> "ELECTION/guid-n_j", where j is the smallest sequence number such that j=
 <
>> i and n_j is a znode in C;"
>>
>>    In my course, I tell them that in this using case=A1A just watch the =
node
>> that only smaller than you, And the meaning of the expression here is
>> inconsistent.
>>
>>    I think the document is error=A1C
>>
>>
>>
>>
>> *nileader* ni=B4x=C2d=AA=BA=AD=D3=A4H=B6l=BDc
>> *MSN*=A1G nileader@gmail.com
>> *Weibo*=A1Ghttp://weibo.com/nileader
>> =A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=
=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1=
X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=
=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X=A1X
>> This email (including any attachments) is confidential and may be legall=
y
>> privileged, private information of correct recipient and nileader. If yo=
u
>> received this email in error, please delete it immediately and do not co=
py
>> it or use it for any purpose or disclose its contents to any other perso=
n.
>> Thank you.
>> *
>>
>> =A5=BB=B9q=B6l(=A5]=ACA=A5=F4=A6=F3=AA=FE=A5=F3)=A5i=AF=E0=A7t=A6=B3=BE=
=F7=B1K=B8=EA=AE=C6=A8=C3=A8=FC=AAk=AB=DF=ABO=C5@=A1A=C4=DD=A9=F3ni=B4x=C2d=
=A9M=A5=BF=BDT=A6=AC=A5=F3=A4H=A4=A7=B6=A1=AA=BA=A8p=A6=B3=ABH=AE=A7=A1C=A6=
p=B1z=A4=A3=ACO=A5=BF=BDT=AA=BA=A6=AC=A5=F3=A4H=A1A=BD=D0=B1z=A5=DF=A7Y=A7R=
=B0=A3=A5=BB=B6l=A5=F3=A1C=BD=D0=A4=A3=ADn=B1N=A5=BB=B9q=B6l=B6i=A6=E6=BD=
=C6=BBs=A8=C3=A5=CE=A7@=A5=F4=A6=F3=A8=E4=A5=A6=A5=CE=B3~=A1A=A9=CE=B3z=C5S=
=A5=BB=B6l=A5=F3=A4=A7=A4=BA=AEe=A1C=C1=C2=C1=C2=A1C
>> *
>>
>>
>>
>> 2012/9/8 Ben Bangert <ben@groovie.org>
>>
>> > As I was implementing read-only mode in the Python client based on the
>> > Java client patch, I noticed a rather odd naming for the error you get=
 if
>> > you send a modification command to a read-only
>> > server...NotReadOnlyException.
>> >
>> > Why the sudden change in error context?
>> >
>> > For reference, here's some of the other errors that Zookeeper may retu=
rn
>> > when making an API call:
>> > NoNode
>> > NoAuth
>> > BadVersion
>> > NoChildrenForEphemerals
>> > NodeExists
>> > NotEmpty
>> >
>> > So the explanation for these errors are consistent, "your API call can=
not
>> > be completed because of this state on the server". Personally, I'm a h=
uge
>> > fan of consistency in an API, so these are all great. But then with
>> > NotReadOnly, we have an error that is not referring to the state of th=
e
>> > server (that it *is* ReadOnly), but one that refers to the semantics o=
f
>> the
>> > API call itself. Given all the other errors, I was really expecting th=
e
>> > server to throw a ReadOnly error indicating your call cannot be comple=
ted
>> > due to that state on the server (like the others).
>> >
>> > Was there a reason for the context switch in error naming? I understan=
d
>> > given its been merged in for almost 2 years now that there's unlikely =
to
>> be
>> > any switch to make it consistent in context with the other errors, but=
 it
>> > might be nice for future feature additions to try and document or enfo=
rce
>> > better consistency in the API.
>> >
>> > Cheers,
>> > Ben
>>