[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12719856#action_12719856
]
Henry Robinson commented on ZOOKEEPER-107:
------------------------------------------
Great comments, thanks very much.
@Benjamin:
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
win.
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.
@Flavio:
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.
