hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henry Robinson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (ZOOKEEPER-368) Observers
Date Mon, 13 Jul 2009 21:31:14 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730522#action_12730522

Henry Robinson commented on ZOOKEEPER-368:

Hi Mahadev - 

To answer your question one by one:

* I think the read-scalability issue is an important use case. Observers are also a natural
way to deal with peers that try to connect but are not part of the current view, which will
be important for the dynamic membership patch. I also would like to use them to publish proposals;
for example they are a convenient point to integrate a larger publish-subscribe system. Watches
are very useful for their intended purposes but are not ideal for listening to a stream of
proposals since they are cancelled once fired. 
* Set peerType=observer in the configuration file to make a peer an observer. In the dynamic
membership patch, a follower that tries to connect while not in the current view will become
an observer until the view is changed to include it.
* Yes, there have been no invasive changes in the Follower code (but some restructuring to
allow code re-use). All tests currently pass for me, which while not conclusive proof, suggests
that there have been no behavioural changes and none are in by design. 
* We must test in the same way we test the behaviour of Followers - their ability to connect,
to see proposals, to withstand stress. Some important observer specific test cases will be:
** Ensuring an observer does not vote in an election or in a proposal (by testing when an
ensemble is not quorate but would be if the observer were a follower)
** Making sure that an observer does not see messages it shouldn't (PROPOSALs in particular)
** Ensuring that an observer does not become a leader.

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

View raw message