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