[
https://issues.apache.org/jira/browse/CURATOR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14333847#comment-14333847
]
ASF GitHub Bot commented on CURATOR-173:
----------------------------------------
Github user cammckenzie commented on the pull request:
https://github.com/apache/curator/pull/67#issuecomment-75640737
@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: 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)
