Peter

> > > Ok! If that is the case, don't you think the existing events (`connecting`, `connect` and `close`) will handle that already, have you tried that out? > >...

> If I understand your question correctly, it sounds like the concept of **leader election**. This is supported by the ZooKeeper client. The ZooKeeper server is an event driven system,...

> Here's examples on the events fired for the connection status of a client: https://github.com/yfinkelstein/node-zookeeper/blob/master/examples/wrapper.js#L36 > > In the example, there's also a suggestion on how to handle disconnects (the...

> You can try the client out by running a local ZooKeeper (I would recommend running it in docker). > > Running ZooKeeper server: > > ```shell > docker run...

> I think the `connecting` event should be triggered actually. Were you running a client towards a ZooKeeper Server in a network (not locally)? Yes, I was connecting to a...

> Interesting! In the recording, the very last thing done is stopping the ZooKeeper server process and the client ends up in a `connecting` state until giving up (the example...

> Thank you for sharing! > > It looks like the Node process exists after a period of being offline from the network ("operation timeout"). I think this is because...

> It's a bit difficult to see, but when I look at your recording again it looks like that you stopped the process, right? Looks like a "session connecting" just...

> If you have more than one client connected, if the leader is disconnected the other registered worker would be the leader. This is directed by the ZooKeeper server. Can...

> I think the `ephemeral` feature of the ZooKeeper server would help you out here. Otherwise, how would you expect an offline client to un-register a leader if it doesn't...