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