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