[
https://issues.apache.org/jira/browse/CURATOR-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396744#comment-15396744
]
Cameron McKenzie commented on CURATOR-337:
------------------------------------------
Thanks for the patch!
> LeaderSelector logs stack trace with "The leader threw an exception" message
> erroneously
> ----------------------------------------------------------------------------------------
>
> Key: CURATOR-337
> URL: https://issues.apache.org/jira/browse/CURATOR-337
> Project: Apache Curator
> Issue Type: Bug
> Components: Client
> Reporter: Mark Payne
>
> I am using the LeaderSelector to choose a leader for a particular role in my
> cluster. Every time that I call close() on the leader selector, I end up with
> the following stack trace in my logs:
> {code}
> 2016-07-20 20:20:47,814 ERROR [Leader Election Notification Thread-1]
> o.a.c.f.recipes.leader.LeaderSelector The leader threw an exception
> java.lang.IllegalMonitorStateException: You do not own the lock:
> /leaders/Cluster Coordinator
> at
> org.apache.curator.framework.recipes.locks.InterProcessMutex.release(InterProcessMutex.java:140)
> ~[curator-recipes-2.10.0.jar:na]
> at
> org.apache.curator.framework.recipes.leader.LeaderSelector.doWork(LeaderSelector.java:425)
> [curator-recipes-2.10.0.jar:na]
> at
> org.apache.curator.framework.recipes.leader.LeaderSelector.doWorkLoop(LeaderSelector.java:441)
> [curator-recipes-2.10.0.jar:na]
> at
> org.apache.curator.framework.recipes.leader.LeaderSelector.access$100(LeaderSelector.java:64)
> [curator-recipes-2.10.0.jar:na]
> at
> org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:245)
> [curator-recipes-2.10.0.jar:na]
> at
> org.apache.curator.framework.recipes.leader.LeaderSelector$2.call(LeaderSelector.java:239)
> [curator-recipes-2.10.0.jar:na]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_74]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_74]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_74]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_74]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_74]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_74]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_74]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_74]
> {code}
> This appears to be due to the fact that in LeaderSelector.doWork(), we call
> mutex.acquire() and then if an InterruptedException is thrown, the finally
> block calls mutex.release() even though the mutex has not been acquired. The
> finally block, then, should read:
> {code}
> if ( hasLeadership )
> {
> hasLeadership = false;
> try
> {
> mutex.release();
> }
> catch ( Exception e )
> {
> ThreadUtils.checkInterrupted(e);
> log.error("The leader threw an exception", e);
> // ignore errors - this is just a safety
> }
> }
> {code}
> That is, we should execute the body of the finally block only if
> hasLeadership == true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
