[
https://issues.apache.org/jira/browse/ZOOKEEPER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12768344#action_12768344
]
Henry Robinson commented on ZOOKEEPER-549:
------------------------------------------
You're right - the observers patch will introduce OBSERVERINFO which is the way
that the leader learns to distinguish observers from followers.
It's also possible that the Leader check its configuration and assigns the
appropriate role to the Learner. However, I'd still like to have the role
negotiated between Learner and Leader and run-time (otherwise we'd have to
check for misconfiguration all throughout the code because an observer would
silently be treated like a follower, never vote and that would be hard to
debug).
In the observers patch, I'll add some code so that if the Leader receives
OBSERVERINFO or FOLLOWERINFO it checks that this is the expected type from that
particular peer.
> Refactor Followers and related classes into a Peer->Follower hierarchy in
> preparation for Observers
> ---------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-549
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-549
> Project: Zookeeper
> Issue Type: Improvement
> Components: quorum, server
> Affects Versions: 3.2.1
> Reporter: Henry Robinson
> Assignee: Henry Robinson
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-549.patch, ZOOKEEPER-549.patch,
> ZOOKEEPER-549.patch, ZOOKEEPER-549.patch
>
>
> For the Observers patch (ZOOKEEPER-368), a lot of functionality is shared
> between Followers and Observers. To avoid copying code, it makes sense to
> push the common code into a parent Peer class and specialise it for Followers
> and Observers. At the same time, some of the lengthier methods in Follower
> can be broken up to make the code more readable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
