[CURATOR-15] LeaderSelector may (undetectably) fail to elect

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 2.0.0-incubating
• Component/s: Recipes
• Assignee: Unassigned
• Reporter: Shevek
• Created: 13/Apr/13 00:35
• Updated: 23/May/23 02:57
• Resolved: 23/May/23 02:57

Description

In LeaderSelector, if mutex.acquire() throws an Exception, for example because CuratorFramework.getZooKeeper() threw a previously-enqueued background exception, then that failure will propagate out of doWork and doWorkLoop, and kill the background submission onto the executor service.

This means that a leaderselector which was start()ed will NEVER elect, and this situation is NOT DETECTABLE externally, since that exception happens on a private executorservice thread and is not client visible. It's impossible to look at a LeaderSelector and decide whether it is still "viable".

This can leave a machine/process "hung" and not automatically recoverable within curator.

Either isQueued() needs to be exposed, which means that a leader is either elected or queued; or the finally{} block which calls clearIsQueued() needs also to set state to CLOSED or FAILED, so that we can query this failure externally.

Issue Links

• incorporates: CURATOR-16 LeaderSelector does not (auto)requeue on session expired
• is fixed by: CURATOR-16 LeaderSelector does not (auto)requeue on session expired
• is fixed by: CURATOR-104 LeaderSelector issue after losing ZooKeeper leader
• relates to: ZOOKEEPER-1683 ZooKeeper client NPE when updating server list on disconnected client