zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jzimmer...@netflix.com>
Subject Re: curator leader election and thread usage
Date Thu, 10 May 2012 17:37:37 GMT
I've decided to add an alternate version of leader selection that doesn't
use threads. It will behave somewhat like a CountDownLatch so I'm calling
it LeaderLatch. I'll report back (only on the Curator list) in the next
day or so when it's available.


On 5/9/12 2:51 PM, "Patrick Hunt" <phunt@apache.org> wrote:

>This might be better directed to the Curator list (ccing them).
>I'm guessing this "thread per leader" is related to a curator pattern?
>Using the ZK api directly you should be able to use a single thread to
>hold multiple leaderships. Perhaps there's a way to get this behavior
>using Curator.
>On Mon, May 7, 2012 at 5:13 AM, john doe <john.doe44210@gmail.com> wrote:
>> Hello,
>> I am currently using curator to manage leader election (which I find
>> nice btw), and I have a question:
>> I am using leaders to manage shards of a database. When a node (=a jvm)
>> started, it is told what shards it could manage if it is elected for
>> shard. A node can be elected for multiple shards.
>> The issue I got is that a node typically manages hundreds of shards. Not
>> sure I understood correctly, but current leader election receipe (as
>> implemented in curator) results in the creation of hundreds of threads,
>> which I keep sleeping because actual processing is done by a separate
>> thread pool.
>> Is there a way not to use that many threads, given that when a node is
>> elected for a shard it will never release its leadership?
>> Thanks
>> John

View raw message