You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Cameron McKenzie (JIRA)" <ji...@apache.org> on 2016/07/28 00:56:20 UTC
[jira] [Resolved] (CURATOR-337) LeaderSelector logs stack trace
with "The leader threw an exception" message erroneously
[ https://issues.apache.org/jira/browse/CURATOR-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cameron McKenzie resolved CURATOR-337.
--------------------------------------
Resolution: Fixed
Assignee: Cameron McKenzie
Fix Version/s: 2.11.1
3.2.1
> 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
> Assignee: Cameron McKenzie
> Fix For: 3.2.1, 2.11.1
>
>
> 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)