hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Carman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-30) Hooks for atomic broadcast protocol
Date Sat, 06 Dec 2008 00:17:44 GMT

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

Andrew Carman commented on ZOOKEEPER-30:

Ben writes:

1)       The leader assigns the zxid. The propose request is asynchronous. Only the leader
issues proposals.

2)       Only the leader proposes. (We have a single proposer.) We just know it has been queued
into the system. And we know the zxid.

3)       No, ephemeral node management is done above the atomic broadcast layer. We don't
need to know which servers are active.

4)       Yes getState and setState belong in the API. State transfers are rather integral
to the atomic broadcast because there is a practical issue: you cannot keep an infinite log
of messages, so you have to be able to summarize, both for storing on disk or for bringing
followers up-to-date. For example, if you are on message 1,0000,000 and a follower comes up
having seen no messages, it is much more efficient to do a state transfer than to dump 1,000,000
messages to the follower. This is a general concept used by both Paxos and Isis, among others.

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

View raw message