[
https://issues.apache.org/jira/browse/CURATOR-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kezhu Wang closed CURATOR-486.
------------------------------
Resolution: Not A Problem
Curator uses {{Guaranteeable.guaranteed}} in deleting lock path. In case of
exception, it will try the deletion in background. So the result is that:
* If session expired, the lock path will be deleted by zk.
* If session not expired, curator will delete it finally in background.
Basically, {{InterProcessMutex.release}} don't supposed to be retried. I rarely
saw retry-able lock release in case of error.
> InterProcessMutex.release fails to remove a lock on retries.
> ------------------------------------------------------------
>
> Key: CURATOR-486
> URL: https://issues.apache.org/jira/browse/CURATOR-486
> Project: Apache Curator
> Issue Type: Bug
> Reporter: Purshotam Shah
> Assignee: Jordan Zimmerman
> Priority: Major
>
> We were planning to build a release lock retry, looks like
> InterProcessMutex.release don't support it.
> It removes currentThread entry from threadData, even if there is an issue
> releasing lock.
> {code:title=InterProcessMutex.java}
> @Override
> public void release() throws Exception
> {
> /*
> Note on concurrency: a given lockData instance
> can be only acted on by a single thread so locking isn't necessary
> */
> Thread currentThread = Thread.currentThread();
> LockData lockData = threadData.get(currentThread);
> if ( lockData == null )
> {
> throw new IllegalMonitorStateException("You do not own the lock:
> " + basePath);
> }
> int newLockCount = lockData.lockCount.decrementAndGet();
> if ( newLockCount > 0 )
> {
> return;
> }
> if ( newLockCount < 0 )
> {
> throw new IllegalMonitorStateException("Lock count has gone
> negative for lock: " + basePath);
> }
> try
> {
> internals.releaseLock(lockData.lockPath);
> }
> finally
> {
> threadData.remove(currentThread);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
