[
https://issues.apache.org/jira/browse/ZOOKEEPER-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-520:
------------------------------------
Summary: add static/readonly client resident serverless zookeeper (was:
add static/readonly client session type)
> add static/readonly client resident serverless zookeeper
> --------------------------------------------------------
>
> Key: ZOOKEEPER-520
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-520
> Project: Zookeeper
> Issue Type: New Feature
> Components: c client, java client
> Reporter: Patrick Hunt
> Fix For: 3.3.0
>
>
> Occasionally people (typically ops) has asked for the ability to start a ZK
> client with a hardcoded, local, non cluster based session. Meaning that you
> can bring up a particular client with a hardcoded/readonly view of the ZK
> namespace even if the zk cluster is not available. This seems useful for a
> few reasons:
> 1) unforseen problems - a client might be brought up and partial application
> service restored even in the face of catastrophic cluster failure
> 2) testing - client could be brought up with a hardcoded configuration for
> testing purposes. we might even be able to extend this idea over time to
> allow "simulated changes" ie - simulate other clients making changes in the
> namespace, perhaps simulate changes in the state of the cluster (testing
> state change is often hard for users of the client interface)
> Seems like this shouldn't be too hard for us to add. The session could be
> established with a URI for a local/remote file rather than a URI of the
> cluster servers. The client would essentially read this file which would be a
> simple representation of the znode namespace.
> /foo/bar "abc"
> /foo/bar2 "def"
> etc...
> In the pure client readonly case this is simple. We might also want to allow
> writes to the namespace (essentially back this with an in memory hash) for
> things like group membership (so that the client continues to function).
> Obv this wouldn't work in some cases, but it might work in many and would
> allow further options for users wrt building a relable/recoverable service on
> top of ZK.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
