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 <[email protected]> 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 <[email protected]> wrote: > >> Hi,all >> >> About “Leader Election”part of zookeeper recipes documention( >> http://zookeeper.apache.org/doc/trunk/recipes.html#sc_leaderElection),many >> 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， just watch the node >> that only smaller than you, And the meaning of the expression here is >> inconsistent. >> >> I think the document is error。 >> >> >> >> >> *nileader* ni掌櫃的個人郵箱 >> *MSN*： [email protected] >> *Weibo*：http://weibo.com/nileader >> ———————————————————————————————————————————————————————————————————————— >> This email (including any attachments) is confidential and may be legally >> privileged, private information of correct recipient and nileader. If you >> received this email in error, please delete it immediately and do not copy >> it or use it for any purpose or disclose its contents to any other person. >> Thank you. >> * >> >> 本電郵(包括任何附件)可能含有機密資料並受法律保護，屬於ni掌櫃和正確收件人之間的私有信息。如您不是正確的收件人，請您立即刪除本郵件。請不要將本電郵進行複製並用作任何其它用途，或透露本郵件之內容。謝謝。 >> * >> >> >> >> 2012/9/8 Ben Bangert <[email protected]> >> >> > 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 return >> > when making an API call: >> > NoNode >> > NoAuth >> > BadVersion >> > NoChildrenForEphemerals >> > NodeExists >> > NotEmpty >> > >> > So the explanation for these errors are consistent, "your API call cannot >> > be completed because of this state on the server". Personally, I'm a huge >> > 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 the >> > server (that it *is* ReadOnly), but one that refers to the semantics of >> the >> > API call itself. Given all the other errors, I was really expecting the >> > server to throw a ReadOnly error indicating your call cannot be completed >> > due to that state on the server (like the others). >> > >> > Was there a reason for the context switch in error naming? I understand >> > 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 enforce >> > better consistency in the API. >> > >> > Cheers, >> > Ben >>
