[
https://issues.apache.org/jira/browse/CURATOR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668284#comment-13668284
]
3l3ph4n1n3 commented on CURATOR-28:
-----------------------------------
Do you mean a thread on the client with the lock, all clients or on the
Zookeeper node? All clients should agree that the lock is unlocked after the
timeout, even if the client who took it misbehaves (e.g. doesn't explicitly
release the lock itself)...
> Add Expiry Time To InterProcessLocks
> ------------------------------------
>
> Key: CURATOR-28
> URL: https://issues.apache.org/jira/browse/CURATOR-28
> Project: Apache Curator
> Issue Type: New Feature
> Components: Recipes
> Affects Versions: 2.0.0-incubating
> Reporter: 3l3ph4n1n3
> Assignee: Jordan Zimmerman
> Priority: Minor
>
> If a client takes a distributed lock and fails without breaking its zookeeper
> connection (e.g. the main application thread deadlocks) then that lock will
> never be released (at least without manual intervention, e.g. killing the
> process that has it). When a client's acquiring a lock I'd like to be able to
> specify a time after which the lock is automatically released. If the client
> currently holds the lock it should be able to extend this time period as many
> times as it likes. A write-up for what I'm describing for redis is here:
> https://chris-lamb.co.uk/posts/distributing-locking-python-and-redis .
> I can see a couple of ways of going about this - the lock lifetime could be
> stored in the node's date (and so clients could check if the node had expired
> by adding the lifetime to the node's ctime or mtime). However, comparing the
> client's current time with the expiry time in the node is probably not the
> right thing to do as the client's clock may be out of sync with the other
> clients (or the zookeeper nodes). It'd be nice if zookeeper could
> automatically delete nodes (i.e. release the lock) after a certain amount of
> time - i.e. make it the zookeeper cluster's decision when the lock is
> expired, not the client's decision. However, I'm not sure exactly how to do
> this...
> Thanks,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
