cyberroadie/zk-leader-single-file — Issue #1: Need a paused state as well
Author: tdunning
Created: 2012-01-05 23:16:39+00:00
State: open

I would recommend elaborating your leader to have three states that include active, inactive and paused. You have the first two states and encode the transitions between them with startSpeaking and stopSpeaking, but you don’t handle the third state. That third state should be entered from the active state on connection loss. From paused state you can return to active if you get a connection event or you can go to inactive if you get an expiration event.

This is important because when you get a disconnection, you don’t know the state of who is the leader. Some applications want to at most one leader and rarely zero, some want to have at least one leader but rarely more and almost never none. The first kind of application will be happy with your setup, but the second kind will not. With a paused state, a leader could choose to stay a leader until told to stop.

The paused state is also very helpful even in the at-most-one kind of application if becoming a leader is expensive. The idea is that a leader in the paused state could refrain from tearing down their service until they are notified that they are no longer leader or an implausibly long time has passed. This avoids the cost of rebuilding or restarting the service if the connection is re-established very quickly as is common.