[jira] Commented: (ZOOKEEPER-30) Hooks for atomic broadcast protocol

["Flavio Paiva Junqueira (JIRA)" <ji...@apache.org>]

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

Flavio Paiva Junqueira commented on ZOOKEEPER-30:
-------------------------------------------------

Currently, the atomic broadcast that ZooKeeper uses is deeply embedded into our implementation. This makes it difficult to change and evaluate the protocol separately. It is desirable then to have hooks for an atomic broadcast implementation to separate the service logic from the protocol.

I have one main concern, though. The service is highly dependent upon a leader as the leader receives operations to propose from followers and it keeps track of sessions. We then have three choices with respect to the leader:

- Eliminate the leader and distribute all functionality across the ZooKeeper servers. In this case, an atomic broadcast might use a leader or not;
- Keep the service leader, but separate it from the atomic broadcast. In this case, the atomic broadcast might still require no single leader;
- Force atomic broadcast protocols to use a leader, and the ZooKeeper leader to be the same as the AB one. 

Check the tutorial of Defago et al. [1] for examples of protocols that do not rely upon a fixed sequencer. To me, the second seems easier to implement given the code base we have, but the first seems cleaner with respect to design.

Currently, the protocol is implemented mostly in Leader.java and Follower.java (Package org.apache.zookeeper.server.quorum). Here is a quick summary of how the code flows:

# It starts by proposing an operation on ProposalRequestProcessor.java: line 65, zks.getLeader().propose(request);
# Leader.propose(request) sends a Leader.PROPOSAL to every follower: line 560 followed by 503, sendPacket(pp). It also adds the request to Leader.outstandingProposals;
# Follower receives a Leader.PROPOSAL: line 223 of Follower.java, case Leader.PROPOSAL;
# Follower sends a Leader.ACK on SendAckRequestProcessor.processRequest(): line 40;
# FollowerHandler? on the leader server receives Leader.ACK and invoke Leader.processAck(): line 295 of FollowerHandler?.java, and line 373 of Leader.java. If there are enough acks for the next expected proposal, then leader commits;
# Leader server commits by removing the head of Leader.outstandingProposals and sending a Leader.COMMIT message to followers: line 519 of Leader.java;
# Follower receives and processes the commit message: line 237 of Follower.java, and line 122 of FollowerZooKeeperServer.java. 

[1] X. Défago, A. Schiper, and P. Urban, "Total order broadcast and multicast algorithms: Taxonomy and survey", in ACM Computing Surveys, Pages: 372 - 421, Volume 36 , Issue 4, December 2004. 

> Hooks for atomic broadcast protocol
> -----------------------------------
>
>                 Key: ZOOKEEPER-30
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-30
>             Project: Zookeeper
>          Issue Type: New Feature
>            Reporter: Patrick Hunt
>            Assignee: Mahadev konar
>
> Moved from SourceForge to Apache.
> http://sourceforge.net/tracker/index.php?func=detail&aid=1938788&group_id=209147&atid=1008547

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.