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

Patrick Hunt updated ZOOKEEPER-520:
-----------------------------------

    Fix Version/s:     (was: 3.3.0)

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

Reply via email to