Session & connection timeout properties; Adding CuratorFrameworkCusto…

[berngp]

We currently don't have a simple mechanism to configure CuratorFramework's session and connection timeout. Since Curator 3.x users can affect how Curator handles re-connection, since the meaning of LOST was changed. In 3.x when the "Disconnected" is received Curator starts an internal timer. When the timer passes the negotiated session timeout Curator calls getTestable().injectSessionExpiration()
and posts a LOST state change.

In Curator 4.x the session timeout defaults to 60 seconds and the connection timeout to 15 seconds.
Ref:

private static final int DEFAULT_SESSION_TIMEOUT_MS = Integer.getInteger("curator-default-session-timeout", 60 * 1000);
private static final int DEFAULT_CONNECTION_TIMEOUT_MS = Integer.getInteger("curator-default-connection-timeout", 15 * 1000);

Proposed Solution

Offer a mechanism to configure the session and connection timeout and establish a mechanism to be able to customize the CuratorFramework for future-proofing.

We could avoid having two more properties, the session and connection timeouts, as part of ZookeeperProperties and let users define them on their CuratorFrameworkCustomizer. The current rational is that consolidating this two configuration properties as part of the spring.cloud.zookeeper configuration namespace is valuable and simplifies how they are used.

Additional Context

Curator will set the LOST state when it believes that the ZooKeeper session has expired.
ZooKeeper connections have a session. When the session expires, clients must take appropriate action.
In Curator, this is complicated by the fact that Curator internally manages the ZooKeeper connection.
Curator will set the LOST state when any of the following occurs:
a) ZooKeeper returns a Watcher.Event.KeeperState.Expired or KeeperException.Code.SESSIONEXPIRED;
b) Curator closes the internally managed ZooKeeper instance;
c) The session timeout elapses during a network partition. It is possible to get a RECONNECTED state after
this but you should still consider any locks, etc. as dirty/unstable.
Ref. Curator Errors

Warning: Curator 4.0.1 is affected by CURATOR-460: Timed tolerance for connection suspended leads to simultaneous leaders. This was addressed in 4.1.0.

Additional references:

• TN14: ZooKeeper's Session Handling
• CURATOR-460
• Curator Errors

[spencergibb]

Overall looks good, just a few small changes.

[TJYS]

CuratorFrameworkCustomizer can't be injected when I use "@bean" ,It's sound like a problem about Loading order

[spencergibb]

@TJYS we have tests that create beans that prove it works.

If you can provide a complete, minimal, verifiable sample that reproduces the problem, please open a new issue. It should be available as a GitHub (or similar) project or attached to the new issue as a zip file.

[TJYS]

@spencergibb if only "spring-cloud-starter-zookeeper-discovery" on the classpath, it works. BUT if I use "spring-cloud-starter-zookeeper-config" at the same time OR only use "spring-cloud-starter-zookeeper-config", it doesn't works. CuratorFrameworkCustomizer can't be injected.
I watched that "ZooKeeperAutoConfiguration" was loaded in different order.

[spencergibb]

Please open a new issue

[TJYS]

OK! I had writen it. #249