hadoop-zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Reed (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ZOOKEEPER-520) add static/readonly client resident serverless zookeeper
Date Tue, 08 Sep 2009 18:01:58 GMT

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

View raw message