[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574414#comment-14574414
]
Rakesh R commented on ZOOKEEPER-2163:
-------------------------------------
Should we write different release version in 3.5 branch and trunk ? like {{New
in 3.5.2}} and {{New in 3.6.0}}. IMHO we could write the same releasing version
in both 3.5 branch and trunk. If this is planning for 3.5.2 then say {{New in
3.5.2}} in 3.5 branch as well as trunk.
> Introduce new ZNode type: container
> -----------------------------------
>
> Key: ZOOKEEPER-2163
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client, java client, server
> Affects Versions: 3.5.0
> Reporter: Jordan Zimmerman
> Assignee: Jordan Zimmerman
> Fix For: 3.6.0
>
> Attachments: zookeeper-2163.10.patch, zookeeper-2163.11.patch,
> zookeeper-2163.12.patch, zookeeper-2163.13.patch, zookeeper-2163.14.patch,
> zookeeper-2163.3.patch, zookeeper-2163.5.patch, zookeeper-2163.6.patch,
> zookeeper-2163.7.patch, zookeeper-2163.8.patch, zookeeper-2163.9.patch
>
>
> BACKGROUND
> ============
> A recurring problem for ZooKeeper users is garbage collection of parent
> nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a
> parent node under which participants create sequential nodes. When the
> participant is done, it deletes its node. In practice, the ZooKeeper tree
> begins to fill up with orphaned parent nodes that are no longer needed. The
> ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can
> become unstable due to the number of these nodes.
> CURRENT SOLUTIONS
> ===================
> Apache Curator has a workaround solution for this by providing the Reaper
> class which runs in the background looking for orphaned parent nodes and
> deleting them. This isn’t ideal and it would be better if ZooKeeper supported
> this directly.
> PROPOSAL
> =========
> ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes
> to contain child nodes. This is not optimum as EPHEMERALs are tied to a
> session and the general use case of parent nodes is for PERSISTENT nodes.
> This proposal adds a new node type, CONTAINER. A CONTAINER node is the same
> as a PERSISTENT node with the additional property that when its last child is
> deleted, it is deleted (and CONTAINER nodes recursively up the tree are
> deleted if empty).
> CANONICAL USAGE
> ================
> {code}
> while ( true) { // or some reasonable limit
> try {
> zk.create(path, ...);
> break;
> } catch ( KeeperException.NoNodeException e ) {
> try {
> zk.createContainer(containerPath, ...);
> } catch ( KeeperException.NodeExistsException ignore) {
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
