curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jordan Zimmerman (JIRA)" <>
Subject [jira] [Resolved] (CURATOR-51) LeaderSelector with custom Executor does not guarantee unique leadership
Date Sat, 07 Sep 2013 02:41:51 GMT


Jordan Zimmerman resolved CURATOR-51.

    Resolution: Fixed

Taking a custom Executor and ThreadFactory wasn't thought through. It's actually useless.
This constructor is now deprecated in favor of passing in an ExecutorService. The old version
is wrapped internally so that it works as it used to. But, it will be removed in the near
> LeaderSelector with custom Executor does not guarantee unique leadership
> ------------------------------------------------------------------------
>                 Key: CURATOR-51
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>          Components: Recipes
>    Affects Versions: 2.2.0-incubating
>            Reporter: Henrik Nordvik
>            Assignee: Jordan Zimmerman
>            Priority: Minor
>             Fix For: 2.2.1-incubating
>         Attachments:, ZookeeperTest.log
> When providing a custom executor to the leader selector it creates a thread that waits
for leadership.
> When it has leadership, it submits a runnable to the custom executor and then release
> If the executor is is e.g. a ThreadPoolExecutor, the takeLeadership method is executed
asynchrounously, after releasing leadership.
> Is this a bug or am I missing the point of using my own executor?
> I have attached an example which shows multiple leaders being elected at the same time.
> (The example uses curator 1.3.3, but I think it is the same in 2.x)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message