[jira] [Commented] (CURATOR-173) InterProcessSemaphoreV2 nodes not reapable

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CURATOR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14314354#comment-14314354 ] 

ASF GitHub Bot commented on CURATOR-173:
----------------------------------------

GitHub user dkesler opened a pull request:

    https://github.com/apache/curator/pull/67

    CURATOR-173

    Adding the notion of a 'lock schema' to ChildReaper that enables it to reap both the direct children its watching and subnodes of those children.  This is necessary with InterProcessSemaphoreV2 as it creates multiple subnodes beneath its lock nodes and otherwise is unreapable with ChildReaper
    
    I'm a little unsure of this solution.  It definitely doesn't make sense for ChildReaper to know about the locks and leases paths for InterProcessSemaphoreV2.  This solution allows a given lock implementation to provide its schema which the ChildReaper can use to clean up for that particular lock.  Currently IPSV2 is the only lock that needs to do so, however.  While more generic than childreaper knowing about lock implementations directly, this still seems a little bruteforcey.  It also wouldn't handle the case where the schema of a lock layout isn't known statically (although they all are currently).    
    
    Another approach might have been to enable childreaper to work recursively, but then it needs to know to not reap the ephemeral nodes created by the lock implementation itself.  (Perhaps simply excluding ephemeral nodes  would work, but it kind of seems like that just "happens to make it work right" rather than because it makes sense for the general concept of child reaping to ignore ephemeral nodes).

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/yodle/curator CURATOR-173

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/curator/pull/67.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #67
    
----
commit 72aea4a30b36201fe2a673358c1e062d6b5109a7
Author: David Kesler <dk...@yodle.com>
Date:   2015-02-09T21:34:20Z

    Adding the notion of a 'lock schema' to ChildReaper that enables it to reap both the direct children its watching and subnodes of those children.  This is necessary with InterProcessSemaphoreV2 as it creates multiple subnodes beneath its lock nodes and otherwise is unreapable with ChildReaper

----


> 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)