hey Benjamin, I've just had a quick look through the code and it seems that it's used internally by Curator when establishing connections to ZK. If a connection is attempted (i.e. a new Zookeeper client handle is instantiated), Curator will allow up to the defined connection timeout MS amount of time to pass to wait for the connection to be established. If it is not established by this point in time it throws away the Zookeeper handle and tries again.
There's actually a warning that gets generated if you attempt to configure the connection timeout > session timeout. I'm not positive of why this is, but I would guess that it's because in this case it would be possible for the session to timeout while waiting for a connection to a dead ZK node? I'm not sure how the underlying ZK handle decides how to connect to a particular ZK instance (it's some sort of random load sharing I think), but I have certainly seen problems when one of the hosts in the ensemble cannot be reached. cheers On Wed, Nov 2, 2016 at 9:03 AM, Benjamin Jaton <[email protected]> wrote: > Hello, > > Is there a documentation somewhere about what connectionTimeoutMs > represents? > > The only thing I could find was: > https://curator.apache.org/apidocs/org/apache/curator/framework/ > CuratorFrameworkFactory.html > > Which simply states: > connectionTimeoutMs - connection timeout > > I am asking because it seems like we HAVE to use a connectionTimeoutMs > that is greater than the sessionTimeout, otherwise we may run into > CURATOR-355 (also if that is the case, it would be nice to just enforce it > or at least log and warn/error). > > Thanks, > Benjamin >
