[ https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575322#comment-14575322 ]
Flavio Junqueira commented on ZOOKEEPER-2163: --------------------------------------------- yeah, I prefer the other approach just because I'd rather avoid spinning threads unnecessarily, even if they are background tasks. given that it has already gone into trunk, I don't think it makes sense to revert it, so let's just keep it in mind. > 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)