[
https://issues.apache.org/jira/browse/CURATOR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336285#comment-14336285
]
ASF GitHub Bot commented on CURATOR-173:
----------------------------------------
Github user cammckenzie commented on a diff in the pull request:
https://github.com/apache/curator/pull/67#discussion_r25326832
--- Diff:
curator-recipes/src/main/java/org/apache/curator/framework/recipes/locks/LockSchema.java
---
@@ -0,0 +1,22 @@
+package org.apache.curator.framework.recipes.locks;
+
+import java.util.HashSet;
+import java.util.Set;
+
+import com.google.common.collect.Sets;
+
+public class LockSchema {
+ private final Set<String> paths;
+
+ public LockSchema() {
+ paths = new HashSet<String>();
--- End diff --
Just nit picking but this should probably be Sets.newHashSet() for
consistency.
> InterProcessSemaphoreV2 nodes not reapable
> ------------------------------------------
>
> Key: CURATOR-173
> URL: https://issues.apache.org/jira/browse/CURATOR-173
> Project: Apache Curator
> Issue Type: Bug
> Reporter: David Kesler
> Assignee: Jordan Zimmerman
>
> The curator documentation recommends using a reaper or childreaper to clean
> up stale lock nodes. This worked for InterProcessSemaphore locks. However
> lock paths that are created by InterProcessSemaphoreV2 cannot be reaped. The
> V2 recipe creates two subnodes beneath the lock node, 'locks' and 'leases',
> which are never cleaned up by the recipe. This ensures that the lock node
> itself will never be empty and thus never reaped. It doesn't seem like
> there's any safe way of handling cleaning up after an InterProcessSemaphoreV2
> using canonical curator recipes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
