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 21:42:13 GMT


ASF GitHub Bot commented on CURATOR-173:

Github user cammckenzie commented on the pull request:
    @dkesler That's a good point, and I guess is going to be an inherent flaw with any implementation
that does not persist the schema somewhere. I guess that persisting the lock schema to ZK
would be a possibility but it seems a bit over engineered. Perhaps your static approach is
the best for now, and we can retrofit something else down the track if we have new locking
implementations that have dynamic schemas.
    I'll hopefully get another chance to look at your patch in a bit more detail today.

> 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