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