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 

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.

Reply via email to