[ https://issues.apache.org/jira/browse/ZOOKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879405#action_12879405 ]
Patrick Hunt commented on ZOOKEEPER-784: ---------------------------------------- I read through the wiki page, I think this is an awesome feature! A few high level questions came to mind: 1) please be clear in the wiki page on b/w compatibility. There's some discussion of this, but what I mean is be very explicit regarding client->server compatibility, server->server compatibility. Have individual sections for this: a) new client new server (obv compat) b) new server new server (ditto) c) new client (using r/o client mode) old server (?) d) new server -> old server (?) 2) be clear on how the client library will search for r/o server vs w/r server (if ensemble has internal partitioning) be clear on how this will work if no servers at all are available. In particular I'm interested in how the client will "backoff" vs hammering (constantly connecting/disconnecting to servers) 3) add use cases that explain to users exactly how this will benefit them. go through some actual use cases such as leader election, group membership, and dynamic config. You should clearly spellout how the user's client code will handle these cases when using r/o mode. You might for example "rewrite" the recipes from the recipes page for the "r/o supported" version. Detail any special considerations the user might need to consider. For example, in the case of leader election you might detail how this is handled from zk perspective (client attached to r/o server) but also detail the considerations the user should have - such as the leader may have changed, what might the user have to consider. (leader can change if client A is connected to r/o server while the rest of the service (other clients of zk) might be connected to a r/w server, during which time the users's leadership changes). etc... We'll need this anyway for the user docs, doing it upfront on the jira will help you both for that and while developing the feature/tests. > server-side functionality for read-only mode > -------------------------------------------- > > Key: ZOOKEEPER-784 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-784 > Project: Zookeeper > Issue Type: Sub-task > Reporter: Sergey Doroshenko > Assignee: Sergey Doroshenko > Attachments: ZOOKEEPER-784.patch, ZOOKEEPER-784.patch, > ZOOKEEPER-784.patch > > > As per http://wiki.apache.org/hadoop/ZooKeeper/GSoCReadOnlyMode , create > ReadOnlyZooKeeperServer which comes into play when peer is partitioned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.