Henry Robinson commented on ZOOKEEPER-107:

Great comments, thanks very much.


You're right that JOIN and LEAVE are special cases of GETVIEW / NEWVIEW. They 
exist only to allow easy expression of what I reckon will be a common pattern: 
"add my node to whatever the current cluster is", otherwise as you say you need 
a GETVIEW for sanity. 

There's an optimisation that would allow JOIN requests to always be committed 
even though the joiner might have failed - the leader can take it as read that 
the joiner implicitly acknowledges the JOIN proposal and can therefore push 
through the commit without requiring an explicit ack from it (you can show 
that, at least for majority quorums, the only way to have a quorum in an old 
view but not in the new under a JOIN is for the joiner to fail). However, since 
the ensemble would be failed immediately afterwards it wouldn't be much of a 

I agree that simple is better; JOIN makes the client programming simpler at the 
expense of the server (and saves the client a round-trip), but functionally 
it's subsumed by the getview->newview pattern. 

I like erroring out when NEWVIEW won't result in a live ensemble, or at least 
having that as an option.


I definitely agree that the persisted state should be in a znode (and should 
therefore be exposable through watches - important for externalising membership 
data for bootstrapping). However, since these operations require a very 
slightly different protocol to normal ZAB, I'm in favour of using the opcode to 
tell the leader to use a protocol variant rather than the identity of the znode 
- this means that the arguments to 'set' or whatever are kept opaque to the 
Leader. This is a matter of taste however - I'm not totally committed to JOIN 
et. al.

> Allow dynamic changes to server cluster membership
> --------------------------------------------------
>                 Key: ZOOKEEPER-107
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: server
>            Reporter: Patrick Hunt
>         Attachments: SimpleAddition.rtf
> Currently cluster membership is statically defined, adding/removing hosts 
> to/from the server cluster dynamically needs to be supported.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to