You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Raul Gutierrez Segales (JIRA)" <ji...@apache.org> on 2013/09/13 19:51:52 UTC

[jira] [Updated] (ZOOKEEPER-1607) Read-only Observer

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raul Gutierrez Segales updated ZOOKEEPER-1607:
----------------------------------------------

    Attachment:     (was: 0001-RFC-Don-t-tear-down-an-Observer-when-we-lose-connect.patch)
    
> Read-only Observer
> ------------------
>
>                 Key: ZOOKEEPER-1607
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1607
>             Project: ZooKeeper
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 3.4.3
>            Reporter: Thawan Kooburat
>         Attachments: persistent-read-only-for-observers.patch
>
>
> This feature reused some of the mechanism already provided by ReadOnlyZooKeeper (ZOOKEEPER-704) but implemented in a different way
> Goal: read-only clients should be able to connect to the observer or continue to read data from the observer event when there is an outage of underling quorum. This means that it is possible for the observer to provide 100% read uptime for read-only local session (ZOOKEEPER-1147)
> Implementation: 
> The observer don't tear down itself when it lose connection with the leader. It only close the connection associated with non read-only sessions and global sessions. So the client can try other observer if this is a temporal failure. 
> During the outage, the observer switch to read-only mode. All the pending and future write requests get will get NOT_READONLY error. Read-only state transition is sent to all session on that observer. The observer only accepts a new connection from a read-only client.
> When the observer is able to reconnect to the leader. It sends state transition (CONNECTED_STATE) to all current session. If it is able to synchronize with the leader using DIFF, the steam of txns is sent through the commit processor instead of applying to the DataTree directly to prevent raise condition between in-flight read requests (see ZOOKEEPER-1505). The client will receive watch events correctly and can start issuing write requests. 
> However, if the observer is getting the snapshot. It need to drop all the connection since it cannot fire a watch correctly.  
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira