[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728429#action_12728429
 ] 

Henry Robinson commented on ZOOKEEPER-107:
------------------------------------------

That's definitely one way to do it. The other side to that argument is to keep 
the message complexity down, especially if we can envisage use cases with lots 
of Observers. A connection to a remote Observer might be more likely to violate 
the FIFO requirement of ZK connections; having a single-message protocol makes 
it easier to deal with this case (not a correctness issue of Observers, just 
annoying if PROPOSALs arrive after COMMITs for some reason). I think that's a 
marginal issue though. My preference is for INFORM messages as this completely 
separates Observer logic from Follower logic and doesn't add much complexity to 
the code. 

The Observer also has to take care not to participate in leader elections. I 
think Observers also need to announce themselves as such to the Leader, to 
enable the case where a Follower wishes to connect as an Observer temporarily 
(otherwise the Leader will think the Observer to be a Follower and use it as 
part of a quorum). Also if the leader can distinguish between followers and 
observers then it can treat both differently (e.g. through batching multiple 
INFORMs or allowing observers to lag by prioritising follower traffic). 

Keeping Observers as special-case Followers would simplify the code for the 
observers patch (I've got a new version nearly ready to submit, just fixing 
some tests). However, it would mean that Observers are harder to customise - 
for example, there's no persistence requirement for an Observer and so some of 
the RequestProcessors can be optionally removed or replaced by something that 
only asynchronously writes to disk. Keeping them lightweight has been a goal. 
My feeling was that I was introducing too many 'if (amObserver()) {...}' 
branches to an already fairly hard to follow bit of code (in particular 
Follower.followLeader). Breaking the functionality into two separate classes 
seems to have made things cleaner.

Regarding Observers being able to issue proposals; I don't have a problem with 
that, should be reasonably easy to add. 

> 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.

Reply via email to