[
https://issues.apache.org/jira/browse/ZOOKEEPER-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386210#comment-15386210
]
Flavio Junqueira commented on ZOOKEEPER-2169:
---------------------------------------------
Great feature, thanks for doing it [~randgalt]. Is it on github or review board
so that it is easier to do review rounds?
One quick question about semantics. The documentation changes seem to say that
TTL nodes are optional for PERSISTENT znodes (and PERSISTENT_SEQUENTIAL), but
the API call does seem to accept EPHEMERAL as well. I'm wondering what the
expected behavior is. I suppose we can down one of three ways:
# The API call only takes PERSISTENT or PERSISTENT_SEQUENTIAL for TTL znodes
# Throws an exception if app tries to create an ephemeral with TTL
# Accept ephemeral + TTL and delete depending on what expires first, session or
TTL.
I don't like the second very much and the first might be a bit messy given our
current API calls.
> Enable creation of nodes with TTLs
> ----------------------------------
>
> Key: ZOOKEEPER-2169
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2169
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client, java client, jute, server
> Affects Versions: 3.6.0
> Reporter: Camille Fournier
> Assignee: Jordan Zimmerman
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2169-2.patch, ZOOKEEPER-2169-3.patch,
> ZOOKEEPER-2169-4.patch, ZOOKEEPER-2169-5.patch, ZOOKEEPER-2169.patch
>
>
> As a user, I would like to be able to create a node that is NOT tied to a
> session but that WILL expire automatically if action is not taken by some
> client within a time window.
> I propose this to enable clients interacting with ZK via http or other "thin
> clients" to create ephemeral-like nodes.
> Some ideas for the design, up for discussion:
> The node should support all normal ZK node operations including ACLs,
> sequential key generation, etc, however, it should not support the ephemeral
> flag. The node will be created with a TTL that is updated via a refresh
> operation.
> The ZK quorum will watch this node similarly to the way that it watches for
> session liveness; if the node is not refreshed within the TTL, it will expire.
> QUESTIONS:
> 1) Should we let the refresh operation set the TTL to a different base value?
> 2) If so, should the setting of the TTL to a new base value cause a watch to
> fire?
> 3) Do we want to allow these nodes to have children or prevent this similar
> to ephemeral nodes?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
