[
https://issues.apache.org/jira/browse/ZOOKEEPER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695589#action_12695589
]
Andrew Carman commented on ZOOKEEPER-30:
----------------------------------------
We'd be happy to show you what we've got, but we don't think we can deliver it
as a patch. We've deleted a large number of files, touched every file in zab,
zab/quorum, and zab/persistence, and changed a lot of the jute generated code.
We're looking at a way to get you public read access to our repository, but
until then is there some other way we could get it to you?
We talked with Jean-Luc today and we all thought it might be a good idea for us
to come back up to LinkedIn at the end of the semester to present our work to
them. Would the Zookeeper team be available to sit in on our presentation and
possibly do a code review (like we did last fall, but reversed) on May 11, 12,
or 13th?
Lastly, we think we've come up with a solution to the returning zxid's problem.
Instead of returning zxid's when you propose, we'll return a ZabTxnCookie
object which can be used to identify which proposals came from yourself and
which came from other nodes. There will be an almost unique local id for each
proposal, and when it is committed, it will also get the zxid, which can be
used by the application layer as a unique id. We propose the signature below.
Any comments or suggestions?
{code:title=ZabTxnCookie.java|borderStyle=solid}
/**
* An identifier for transactions that should be opaque to the user but useful
* for comparing if two transactions are the same or not. By design it is used
* by systems implementing the Zab and ZabCallback interfaces because a
* ZabTxnCookie will be returned when you make a proposal (and a sync) and
* then passed when commit is called so that the client can match their
* proposals with commits.
*/
public class ZabTxnCookie {
/**
* A unique identifier for each server, this is assigned by the config
* files when Zab is being set up.
*/
private long serverId;
/**
* The zxid assigned by the leader to a committed proposal. This will only
* exist on committed proposals once they are passed to deliver. This CAN
* be used as a unique identifier for each proposal.
*/
private long zxid;
/**
* A probably unique identifier for each proposal. Its most significant
* 32-bits are the bottom 32-bits of the system time in milliseconds when
* the node starts up (so it's reset each time the server goes down). The
* bottom 32-bits are just a counter that's incremented on each proposal.
* So this number will not be unique if the server goes down and starts up
* exactly n*2^32 milliseconds after the first time (n>0).
*/
private long localId;
public boolean equals(ZabTxnCookie other);
/**
* Returns a unique identifier for this proposal, however the identifier
* is only valid for proposals that have been committed. So this method
* should only be called once a transaction is delivered to you, never
* just after making a proposal. This identifier is guaranteed to be
* sequentially increasing and unique even across server failures.
*
* @return A unique identifier for this proposal if it has been committed,
* otherwise this number is invalid.
*/
public long getUniqueId();
}
{code}
> 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.
