[
https://issues.apache.org/jira/browse/CURATOR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329972#comment-14329972
]
ASF GitHub Bot commented on CURATOR-173:
----------------------------------------
Github user cammckenzie commented on the pull request:
https://github.com/apache/curator/pull/67#issuecomment-75354182
I've had a brief look at this, and I think it looks ok.
A quick thought about allowing for dynamic change to the schema, is it
better to get the lock implementation instance to return a reference to an
instance of the LockSchema object that is specific to that particular lock
instance? The lock implementation could then update this reference with any
dynamic content?
Obviously this would add the need for synchronisation etc.
> 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)
