curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CURATOR-173) InterProcessSemaphoreV2 nodes not reapable
Date Mon, 23 Feb 2015 15:46:11 GMT


ASF GitHub Bot commented on CURATOR-173:

Github user dkesler commented on the pull request:
    @cammckenzie The problem with requiring passing the lock instance to the reaper to get
the lock schema is that you can end up leaking locks.  If the app that took the lock doesn't
successfully clean it up then other processes won't know the schema of that particular lock
instance since they need an instance of the lock in order to clean it up.
    Not entirely sure if it's a huge concern, but I thought I'd point it out since I don't
have insight as to possible future lock incarnations.    

> InterProcessSemaphoreV2 nodes not reapable
> ------------------------------------------
>                 Key: CURATOR-173
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message