[
https://issues.apache.org/jira/browse/CURATOR-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668892#comment-13668892
]
3l3ph4n1n3 commented on CURATOR-28:
-----------------------------------
My problem is that a single client shouldn't be trusted to unlock the lock
itself - the point of this failsafe is to ensure a system doesn't grind to a
halt when a single client fails. There are many ways a client's lockTimer could
fail yet the client's heartbeating to the zookeeper cluster continued - e.g. if
the lockTimer thread had a bug in it and crashed, or deadlocked itself with
another thread. Ideally the remaining clients would decide a bit later that the
lock's lease time had expired, forcefully release the lock from the broken
client and then one of them would acquire 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
