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.

Reply via email to