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