Yes, I mentioned this over a year and a half ago: -
looks like it still hasn't been rectified.
On 11 September 2012 11:13, nileader <[EMAIL PROTECTED]> wrote:
> About “Leader Election”part of zookeeper recipes documention(
> 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
> I think the document is error。
> *nileader* ni掌櫃的個人郵箱
> *MSN*： [EMAIL PROTECTED]
> 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.
> 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
> > 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
> > 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