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

Reply via email to