[
https://issues.apache.org/jira/browse/CURATOR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16856890#comment-16856890
]
Jordan Zimmerman commented on CURATOR-527:
------------------------------------------
BTW [~jc5201] I don't think you're pseudo code will work well. For example,
this method:
{code}
class Watcher1 extends BaseWatcher {
@Override
public void process(WatchedEvent watchedEvent) {
try {
super.lock();
registerWatcher(this, false);
super.unlock();
}
}
}
{code}
This will almost certainly cause a deadlock. Inside of a ZooKeeper watcher you
should never take any action that might block. This is because you will block
ZooKeeper's main processing thread and this prevents any other operations from
happening. We have a Tech Note about this here:
https://cwiki.apache.org/confluence/display/CURATOR/TN1
I imagine this is why you are seeing locks not acquire in your system.
> Concurrency issue in LockInternals
> ----------------------------------
>
> Key: CURATOR-527
> URL: https://issues.apache.org/jira/browse/CURATOR-527
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 2.12.0
> Environment: Curator 2.12.0
> zookeeper 3.4.14
> Reporter: Kim Jaechang
> Priority: Major
>
> I'm using InterProcessMutex and InterProcessMutex often failed to acquire
> lock.
> In LockInternals.internalLockLoop(), watcher is registered to zookeeper and
> call wait() like below
> {code:java}
> client.getData().usingWatcher(watcher).forPath(previousSequencePath);
> if ( millisToWait != null )
> {
> millisToWait -= (System.currentTimeMillis() - startMillis);
> startMillis = System.currentTimeMillis();
> if ( millisToWait <= 0 )
> {
> doDelete = true; // timed out - delete our node
> break;
> }
> wait(millisToWait);
> }
> else
> {
> wait();
> }
> {code}
> In my case, my program is waiting
> previousSequencePath=_c_f290140d-9856-42ad-b9bf-348ffc086062-lock-0000000759
> to be deleted.
> But _c_f290140d-9856-42ad-b9bf-348ffc086062-lock-0000000759 is deleted
> between client.getData() and wait().
> if _c_f290140d-9856-42ad-b9bf-348ffc086062-lock-0000000759 is deleted when
> client.getData().usingWatcher(watcher).forPath(previousSequencePath) is
> called, it will throw Exception but it was exist at that time.
> I'm using Curator 2.12.0 but latest version seems to have same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
