curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-337) LeaderSelector logs stack trace with "The leader threw an exception" message erroneously
Date Thu, 28 Jul 2016 00:24:20 GMT

    [ https://issues.apache.org/jira/browse/CURATOR-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396709#comment-15396709
] 

ASF GitHub Bot commented on CURATOR-337:
----------------------------------------

GitHub user markap14 opened a pull request:

    https://github.com/apache/curator/pull/159

    CURATOR-337: Do not attempt to release a mutex unless it has actually been acquired

    Do not attempt to release a mutex unless it has actually been acquired

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/markap14/curator CURATOR-337

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/curator/pull/159.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #159
    
----
commit 6cebfc13ccdcd9cb2a5b576fa369b957e651752a
Author: Mark Payne <markap14@hotmail.com>
Date:   2016-07-28T00:23:13Z

    CURATOR-337: Do not attempt to release a mutex unless it has actually been acquired

----


> 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)

Mime
View raw message