Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
MIME-Version: 1.0
In-Reply-To: <1258CA91-21B1-4753-840E-677D5EDD2C87@jordanzimmerman.com>
References: <JIRA.12821659.1429215707656@arcas> <JIRA.12821659.1429215707000@Atlassian.JIRA>
 <JIRA.12821659.1429215707000.182316.1470015080904@Atlassian.JIRA>
 <CAAUywg8n-fz4+r2Vdos4BeN3Xj+J9azsUAY3iTRw8Sw99SF_CA@mail.gmail.com> <1258CA91-21B1-4753-840E-677D5EDD2C87@jordanzimmerman.com>
From: =?UTF-8?Q?Stevo_Slavi=C4=87?= <sslavic@gmail.com>
Date: Mon, 1 Aug 2016 18:02:18 +0200
Message-ID: <CAAUywg-dYFtoN2M=o-aC3wRqGrMpuYcHDhsHEXVPL+OzesTpeA@mail.gmail.com>
Subject: Re: [jira] [Comment Edited] (ZOOKEEPER-2169) Enable creation of nodes
 with TTLs
To: dev@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=047d7ba970769d4826053904b948
archived-at: Mon, 01 Aug 2016 16:02:35 -0000

--047d7ba970769d4826053904b948
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <jordan@jordanzimmerman.co=
m
> wrote:

> That=E2=80=99s an interesting idea - so a watcher for container expiratio=
ns?
>
> -Jordan
>
> > On Aug 1, 2016, at 2:20 AM, Stevo Slavi=C4=87 <sslavic@gmail.com> 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 ab=
le
> > 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 bee=
n
> > 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) <
> > jira@apache.org> wrote:
> >
> >>
> >>    [
> >>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2169?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1540=
1429#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 othe=
r
> >> "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 vi=
a
> a
> >> refresh operation.
> >>> The ZK quorum will watch this node similarly to the way that it watch=
es
> >> 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 bas=
e
> >> 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)
> >>
>
>

--047d7ba970769d4826053904b948--