3l3ph4n1n3 created CURATOR-28:
---------------------------------
Summary: 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
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
