Yes, all server side. Client that successfully creates TTL node and registers such "trigger", could disconnect - trigger should fire on TTL node deletion and be handled on server side only. So server watching and handling event. It shouldn't happen that TTL node gets deleted and event does not get handled - both deletion of TTL node and handling of a trigger both should either succeed or fail.
On Mon, Aug 1, 2016 at 5:37 PM, Jordan Zimmerman <[email protected] > wrote: > That’s an interesting idea - so a watcher for container expirations? > > -Jordan > > > On Aug 1, 2016, at 2:20 AM, Stevo Slavić <[email protected]> wrote: > > > > Hello Apache ZooKeeper developers, > > > > Thinking, for a use case like support temporary topics in Apache Kafka, > > which could be based on ZooKeeper TTL feature, might be useful to be able > > to register a ZooKeeper "trigger" once TTL expires for a node - e.g. in > > same transaction that deletes temporary node, create another persistent > > node (request to delete the topic). Of course one could workaround this, > by > > creating persistent and TTL node, and check if there is persistent node > > without matching temporary node, but option with trigger would have been > > better/easier from consistency point of view. > > > > What do you think about the idea? > > > > Kind regards, > > Stevo Slavic. > > > > > > On Mon, Aug 1, 2016 at 3:31 AM, Raul Gutierrez Segales (JIRA) < > > [email protected]> wrote: > > > >> > >> [ > >> > https://issues.apache.org/jira/browse/ZOOKEEPER-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401429#comment-15401429 > >> ] > >> > >> Raul Gutierrez Segales edited comment on ZOOKEEPER-2169 at 8/1/16 1:31 > AM: > >> > --------------------------------------------------------------------------- > >> > >> [~fpj]: it's here: https://reviews.apache.org/r/46983/. > >> > >> cc: [~randgalt] > >> > >> > >> was (Author: rgs): > >> [~fpj]: it's here. > >> > >> cc: [~randgalt] > >> > >>> 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) > >> > >
