[
https://issues.apache.org/jira/browse/ZOOKEEPER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688994#action_12688994
]
Andrew Carman commented on ZOOKEEPER-30:
----------------------------------------
Update: We just got Multi-Zab up and running (our name for the multinode,
networked version of Zab - basically we moved over all of the quorum
components). We're working on preliminary testing and have already found and
fixed a few bugs we introduced. We're continuing now with more thorough testing
(eventually some performance as well as functionality tests) and code
maintenance (comments, refactoring, etc). The only features we're missing are
syncs and the ability to return a zxid when calling propose. Syncs are
definitely a feature we will add (in the manner they exist now, so we avoid the
two round trips of atomic broadcast), but we would like some input on returning
zxid's.
How should they work? When a Zab node has the propose method called on it, the
API says it should return a zxid of that proposal. However, the leader has to
assign the zxid, so we either need the client to wait for the proposal to be
sent to the leader, assigned a zxid, and sent back out to be voted on, or we
don't return a zxid. Is there a reason we need to return zxid's? Is it only so
implementing applications can identify which committed proposals originated
from themselves? Could we just add a server id and local id instead of having
to wait for the zxid from the leader?
> Hooks for atomic broadcast protocol
> -----------------------------------
>
> Key: ZOOKEEPER-30
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-30
> Project: Zookeeper
> Issue Type: New Feature
> Components: quorum
> 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.
