Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Use cases for ZooKeeper


Copy link to this message
-
Re: Use cases for ZooKeeper
They're stored in ZooKeeper, so both. ZooKeeper backs everything to disk
but keeps the entire DB in memory for performance.

-JZ

On 1/5/12 10:54 AM, "Josh Stone" <[EMAIL PROTECTED]> wrote:

>Are the distributed queue and locks written to disk or can they be held in
>memory?
>
>josh
>
>On Thu, Jan 5, 2012 at 10:02 AM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> Curator's queue handles a node going down (when you use setLockPath()).
>> Curator will hold a lock for each message that is being processed. You
>>can
>> see the implementation in the method processWithLockSafety() here:
>>
>>https://github.com/Netflix/curator/blob/master/curator-recipes/src/main/j
>>av
>> a/com/netflix/curator/framework/recipes/queue/DistributedQueue.java
>>
>> >Will a node going down still clear any distributed locks?
>> Yes.
>>
>>
>> -JZ
>>
>> On 1/5/12 9:56 AM, "Josh Stone" <[EMAIL PROTECTED]> wrote:
>>
>> >Yes, something like that with lock safety would satisfy my third use
>>case.
>> >
>> >Some questions: Is the distributed queue effectively located by a
>>single
>> >z-node? What happens when that node goes down? Will a node going down
>> >still
>> >clear any distributed locks?
>> >
>> >Josh
>> >
>> >On Thu, Jan 5, 2012 at 9:41 AM, Jordan Zimmerman
>> ><[EMAIL PROTECTED]>wrote:
>> >
>> >> FYI - Curator has a resilient message Queue:
>> >> https://github.com/Netflix/curator/wiki/Distributed-Queue
>> >>
>> >> On 1/5/12 5:00 AM, "Inder Pall" <[EMAIL PROTECTED]> wrote:
>> >>
>> >> >Third use case: Fault tolerance. If we utilized ZooKeeper to
>>distribute
>> >> >messages to workers, can it be made to handle a node going down by
>> >> >re-distributing the work to another node (perhaps messages that are
>>not
>> >> >ack'ed within a timeout are resent)?
>> >>
>> >>
>>
>>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB