You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Marc Celani (Created) (JIRA)" <ji...@apache.org> on 2011/11/05 03:05:51 UTC
[jira] [Created] (ZOOKEEPER-1290) zookeeper_init_with_watches
zookeeper_init_with_watches
---------------------------
Key: ZOOKEEPER-1290
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1290
Project: ZooKeeper
Issue Type: New Feature
Components: c client
Reporter: Marc Celani
Our use of zookeeper requires high scalability, and the underlying data set is small and changes infrequently. A persisted cache is ideal for solving scalability. We want to treat a restart as if it were a prolonged reconnect - that is, maintain the last known zxid and watch list. We would like to expose a new zookeeper_init_with_watches api that allows the zhandle to be initialized with the watch list and last known zxid. The change would reuse the current reconnect logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1290) zookeeper_init_with_watches
Posted by "Patrick Hunt (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144597#comment-13144597 ]
Patrick Hunt commented on ZOOKEEPER-1290:
-----------------------------------------
bq. You'll be bounded by the session timeout. That's acceptable?
I meant session expiration. If the server doesn't hear from the client within the session timeout it will expire the session. If your client takes longer than this to restart it's session would be expired and it wouldn't be able to reconnect.
http://zookeeper.apache.org/doc/r3.3.3/zookeeperProgrammers.html#ch_zkSessions
> zookeeper_init_with_watches
> ---------------------------
>
> Key: ZOOKEEPER-1290
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1290
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client
> Reporter: Marc Celani
>
> Our use of zookeeper requires high scalability, and the underlying data set is small and changes infrequently. A persisted cache is ideal for solving scalability. We want to treat a restart as if it were a prolonged reconnect - that is, maintain the last known zxid and watch list. We would like to expose a new zookeeper_init_with_watches api that allows the zhandle to be initialized with the watch list and last known zxid. The change would reuse the current reconnect logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1290) zookeeper_init_with_watches
Posted by "Patrick Hunt (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144583#comment-13144583 ]
Patrick Hunt commented on ZOOKEEPER-1290:
-----------------------------------------
You'll be bounded by the session timeout. That's acceptable?
Also it would be good if you add to both c and java given we want to maintain feature parity btw the clients.
> zookeeper_init_with_watches
> ---------------------------
>
> Key: ZOOKEEPER-1290
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1290
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client
> Reporter: Marc Celani
>
> Our use of zookeeper requires high scalability, and the underlying data set is small and changes infrequently. A persisted cache is ideal for solving scalability. We want to treat a restart as if it were a prolonged reconnect - that is, maintain the last known zxid and watch list. We would like to expose a new zookeeper_init_with_watches api that allows the zhandle to be initialized with the watch list and last known zxid. The change would reuse the current reconnect logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1290) zookeeper_init_with_watches
Posted by "Marc Celani (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144605#comment-13144605 ]
Marc Celani commented on ZOOKEEPER-1290:
----------------------------------------
Yes this is fine, although I am allowing the client to initialize with watches even if they do not report a previous session (more like reconnect to a second server in a list of servers, where you send a set watch request). That's actually my use case. The implementation will still respect existing session expiration logic when the client supplies a client id.
> zookeeper_init_with_watches
> ---------------------------
>
> Key: ZOOKEEPER-1290
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1290
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client
> Reporter: Marc Celani
>
> Our use of zookeeper requires high scalability, and the underlying data set is small and changes infrequently. A persisted cache is ideal for solving scalability. We want to treat a restart as if it were a prolonged reconnect - that is, maintain the last known zxid and watch list. We would like to expose a new zookeeper_init_with_watches api that allows the zhandle to be initialized with the watch list and last known zxid. The change would reuse the current reconnect logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1290) zookeeper_init_with_watches
Posted by "Marc Celani (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144591#comment-13144591 ]
Marc Celani commented on ZOOKEEPER-1290:
----------------------------------------
Patrick,
I'm not sure I'm understanding your comment about being bounded to the session timeout. My implementation of init_with_watches is exactly the same as zookeeper_init except that it will initialize the watch hash tables with values and the last_zxid with a given value. On connect, the current c implementation will send the set watches for me (even though it is not a reconnect). It will still require a session timeout be given and will respect it. It's not clear to me what my change has to do with session timeouts.
Adding to java sounds reasonable.
Marc
> zookeeper_init_with_watches
> ---------------------------
>
> Key: ZOOKEEPER-1290
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1290
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client
> Reporter: Marc Celani
>
> Our use of zookeeper requires high scalability, and the underlying data set is small and changes infrequently. A persisted cache is ideal for solving scalability. We want to treat a restart as if it were a prolonged reconnect - that is, maintain the last known zxid and watch list. We would like to expose a new zookeeper_init_with_watches api that allows the zhandle to be initialized with the watch list and last known zxid. The change would reuse the current reconnect logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira