[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722245#action_12722245
]
Henry Robinson edited comment on ZOOKEEPER-107 at 6/20/09 12:09 PM:
--------------------------------------------------------------------
As it turns out, I've pretty much implemented Observers in all but name already
- they go through the same connection logic as normal followers, and therefore
sync, but are disbarred from sending Leader.REQUEST packets to the leader.
Similarly, when a leader is sending a proposal packet it only gets sent to
those followers which are in the current view. Since the logic is very similar,
and we will be able to distinguish observers from followers by whether they are
members of the current view, I haven't duplicated code into Observer* classes.
I added this when finding that any new follower can join an existing ensemble
and issue proposals to it, even if the static configuration of the ensemble
does not contain it. This seemed to deadlock the ensemble pretty quickly :)
Edit: of course, this means that Observers can't actually see the payload of a
transaction, as per the note on ZK-368. Either the leader sends special packets
(INFORM, perhaps) to Observers containing the transaction payload, or the
Observers must know not to participate in voting. That said, the Leader will
ignore the votes of Observers, but we want to cut down on traffic.
was (Author: henryr):
As it turns out, I've pretty much implemented Observers in all but name
already - they go through the same connection logic as normal followers, and
therefore sync, but are disbarred from sending Leader.REQUEST packets to the
leader. Similarly, when a leader is sending a proposal packet it only gets sent
to those followers which are in the current view. Since the logic is very
similar, and we will be able to distinguish observers from followers by whether
they are members of the current view, I haven't duplicated code into Observer*
classes.
I added this when finding that any new follower can join an existing ensemble
and issue proposals to it, even if the static configuration of the ensemble
does not contain it. This seemed to deadlock the ensemble pretty quickly :)
> 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
> Assignee: Henry Robinson
> 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.
