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 

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.

Reply via email to