[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517429#comment-14517429
]
Raul Gutierrez Segales commented on ZOOKEEPER-2163:
---------------------------------------------------
Oh - right. Also, not sure if this is new:
{noformat}
.....
[exec] [junit] 2015-04-17 17:36:23,750 [myid:] - ERROR
[QuorumPeer[myid=4](plain=/0:0:0:0:0:0:0:0:11235)(secure=disabled):QuorumPeer@1394]
- writeToDisk == true but configFilename == null
.....
{noformat}
Though that error statement doesn't actually do any proper error handling in
QuorumPeer#setQuorumVerifier. I'll follow-up w/ [~shralex] on another ticket.
> 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
> Attachments: zookeeper-2163.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)
