[ZOOKEEPER-2368] Client watches are not disconnected on close

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.4.0, 3.5.0
• Fix Version/s: 3.6.0, 3.5.5
• Labels: pull-request-available
• Assignee: Timothy James Ward
• Reporter: Timothy James Ward
• Created: 15/Feb/16 09:28
• Updated: 20/May/19 17:50
• Resolved: 20/Jun/18 13:23

Description

If I have a ZooKeeper client connected to an ensemble then obviously I can register watches.

If the client is disconnected (for example by a failing ensemble member) then I get a disconnection event for all of my watches. If, on the other hand, my client is closed then I do not get a disconnection event. This asymmetry makes it really hard to clear up properly when using the asynchronous API, as there is no way to "fail" data reads/updates when the client is closed.

I believe that the correct behaviour should be for all watchers to receive a disconnection event when the client is closed. The watchers can then respond as appropriate, and can differentiate between a "server disconnect" and a "client disconnect" by checking the ZooKeeper#getState() method.

This would not be a breaking behaviour change as Watchers are already required to handle disconnection events.

Issue Links

• supercedes: CURATOR-377 Curator should have an option to send KeeperState.Expired to watchers when a ZK handle is closed
• links to: GitHub Pull Request #529