curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Payne (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CURATOR-337) LeaderSelector logs stack trace with "The leader threw an exception" message erroneously
Date Wed, 27 Jul 2016 19:56:20 GMT
Mark Payne created CURATOR-337:
----------------------------------

             Summary: 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