Can you give a more detailed example? In ZooKeeper, a server writes a unique value to the ZK cluster and, if successful, proceeds to do its work. This is the majority case. Curator’s leader recipes implement this. Are you saying, that you elect a leader but another instance does the work? Why would you need this?
-JZ On January 27, 2015 at 2:10:57 PM, Ricardo Ferreira ([email protected]) wrote: I was using leadership status to restrict the node who acts upon an action request. Actions don't necessarily originate from a leader node. If the leader goes down actions are still requested... But the way I'm modeling it and from what you said, it seems they'll be lost. On Tue, Jan 27, 2015 at 7:05 PM, Jordan Zimmerman <[email protected]> wrote: The actions will be performed by the leader node. So, if the leader goes down no actions occur. So, I don’t follow your concern. On January 27, 2015 at 2:04:03 PM, Ricardo Ferreira ([email protected]) wrote: Sure, I understand that. There are also no guarantees if the leader node goes down and an action must be performed in between heartbeats The Zookeeper client wont yet be aware a node is down and the cluster's state will be inconsistent, right? On Tue, Jan 27, 2015 at 5:54 PM, Jordan Zimmerman <[email protected]> wrote: No. If a non-leader dies there is not a new leader election. The current leader stays leader. -JZ On January 27, 2015 at 12:50:43 PM, Ricardo Ferreira ([email protected]) wrote: And from what you described, it gets worse: If a non-leader dies, leadership election will take place and a new leader might be elected, right?
