Patrick Hunt commented on ZOOKEEPER-368:

Last night I was thinking about this, "368 - why the disconnect?" and I believe 
I have figured out the underlying issue. JIRAs are primarily problem statements 
and resolutions (patches for the most part). In this case the solution doesn't 
fit the problem statement "subject: Observers". This is not observers, really 
it's more like "phase 1 of Observers - code changes and tests, limited 
functionality (UDP LE only)" with additional JIRAs to address subsequent to 
this patch going in.  I know when I reviewed this patch, and if you look at my 
most recent comments, this is the mindset I had - "this is observers", but 
really that's not Henry's intent. That's fine from my perspective, iterative 
development is great, improve things but don't break existing functionality, 
but the JIRA description here (esp subject) doesn't fit and that's throwing 
people. Creating additional JIRAs would also make this more clear ("obs phase 2 
adding ...", "phase 3 finalizing observers, code complete" -- whatever). 
Changing the subject on this JIRA would make this more clear.

Ben had a good summary of next steps so I won't go through that. Flavio and 
Henry seem to have a plan in place to execute. So lets wrap this up boys and 
girls. ;-)

Finally, I want to point out that if a patch takes 5 months or 5 years, if it's 
not ready to go in it's not ready, regardless of outside pressure. It's the 
contributor's responsibility to work with the committers to get a patch 
committed. It's the committers responsibility to work with the contributor, 
review the patch, provide useful feedback and try to get the issues resolved 
with limited muss/fuss.

Henry, you've been doing a great job on this (and support of ZK in general). I 
know both you and Flavio (and the rest of the committers) have been spending a 
lot of time on this - thanks all! So like I said, let's wrap this up and move 

> Observers
> ---------
>                 Key: ZOOKEEPER-368
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: quorum
>            Reporter: Flavio Paiva Junqueira
>            Assignee: Henry Robinson
>         Attachments: obs-refactor.patch, observer-refactor.patch, observers 
> sync benchmark.png, observers.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, 
> ZOOKEEPER-368.patch
> Currently, all servers of an ensemble participate actively in reaching 
> agreement on the order of ZooKeeper transactions. That is, all followers 
> receive proposals, acknowledge them, and receive commit messages from the 
> leader. A leader issues commit messages once it receives acknowledgments from 
> a quorum of followers. For cross-colo operation, it would be useful to have a 
> third role: observer. Using Paxos terminology, observers are similar to 
> learners. An observer does not participate actively in the agreement step of 
> the atomic broadcast protocol. Instead, it only commits proposals that have 
> been accepted by some quorum of followers.
> One simple solution to implement observers is to have the leader forwarding 
> commit messages not only to followers but also to observers, and have 
> observers applying transactions according to the order followers agreed upon. 
> In the current implementation of the protocol, however, commit messages do 
> not carry their corresponding transaction payload because all servers 
> different from the leader are followers and followers receive such a payload 
> first through a proposal message. Just forwarding commit messages as they 
> currently are to an observer consequently is not sufficient. We have a couple 
> of options:
> 1- Include the transaction payload along in commit messages to observers;
> 2- Send proposals to observers as well.
> Number 2 is simpler to implement because it doesn't require changing the 
> protocol implementation, but it increases traffic slightly. The performance 
> impact due to such an increase might be insignificant, though.
> For scalability purposes, we may consider having followers also forwarding 
> commit messages to observers. With this option, observers can connect to 
> followers, and receive messages from followers. This choice is important to 
> avoid increasing the load on the leader with the number of observers. 

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