I see your point. The Container works as a double barrier, but not a single barrier. What’s interesting is that we could combine a Container with a TTL to get the single barrier. Allow Containers to have a TTL so that they aren’t deleted until a) they’ve had at least 1 child; b) they no longer have any children; c) TTL has elapsed without the Container being modified. The downside is that this forces the barrier to exist for the full length of the TTL.
Regarding immediate container deletion, that wouldn’t be hard to add. > On May 4, 2016, at 4:14 PM, Flavio Junqueira <f...@apache.org> wrote: > > I was thinking of the following situation. Say that I have two clients > participating in the barrier. The first one immediately adds a node to the > container, but the other client is a bit slow. The first client crosses the > barrier and deletes the corresponding child. If the other client is still > slow and doesn't add a child node to the container, then the container > manager will delete the container incorrectly, indicating that everyone has > crossed the barrier. I suppose the way around it is to have all clients > waiting until everyone has added a child to the container, for that, all > clients need to know the number of children to expect and even that can be > tricky because a getChildren after a notification might miss a znode that has > already been deleted. > > The issue, which is kind of arguable whether it is an issue or not, is that > I'd expect the container to go away as soon as the last child is deleted > rather than wait until the container manager deletes it. We could for example > expose a deleteContainer call and fail it if the delete condition doesn't > match. The delete condition could be no children or perhaps no children and > cversion >= number of clients in the barrier. > > -Flavio > >> On 04 May 2016, at 18:32, Jordan Zimmerman <jor...@jordanzimmerman.com> >> wrote: >> >> Containers do not get deleted if they’ve never had children (the cversion >> must be > 0). Also, containers are not deleted until they have no children. >> So, it does seem like a perfect fit. I don’t think the issue you listed are >> a concern unless I misunderstand. >> >> -Jordan >> >>> On May 4, 2016, at 12:01 PM, Flavio Junqueira <f...@apache.org> wrote: >>> >>> Thanks, Jordan. Given that this is in the context of containers, after a >>> discussion offline with Ben, we were wondering what we would need to do to >>> implement barriers with containers. >>> >>> A couple of issues we see are that: >>> >>> - The container manager could potentially end up deleting a container even >>> before all nodes have joined the barrier by creating a child. >>> - We depend on the container manager to delete the container, and it might >>> be better for barriers to enable it to be deleted explicitly upon the last >>> node crossing the barrier (deleting the last child). >>> >>> Any thoughts here? >>> >>> -Flavio >>> >>>> On 04 May 2016, at 17:28, Jordan Zimmerman <jor...@jordanzimmerman.com> >>>> wrote: >>>> >>>> FYI >>>> >>>> I’ve posted an implementation for TTL Nodes, >>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2169 >>>> <https://issues.apache.org/jira/browse/ZOOKEEPER-2169> >>>> >>>> https://reviews.apache.org/r/46983/ <https://reviews.apache.org/r/46983/> >>>> >>>> -Jordan >>> >> >
