connectionTimeout is how long you’re willing to wait before the initial connection to ZK - i.e. until Curator gets SysConnected. It’s really just as simple as that. The warning occurs because Curator 3.0 now injects a “fake” session timeout if notices a lapse of the session timeout. So, if sessionTimeout is less than connectionTimeout, the sessionTimeout will always take precedence.
How you set the values is entirely up to you. When I write ZK applications I use a sessionTimeout in the 60 second or greater range. I would not want to wait 1 minute before I knew that a cluster was unavailable. Therefore, I’d use a connectionTimeout of 10 seconds and a sessionTimeout of 60. -JZ > On Nov 1, 2016, at 5:37 PM, Benjamin Jaton <[email protected]> wrote: > > > > On Tue, Nov 1, 2016 at 3:26 PM, Cameron McKenzie <[email protected] > <mailto:[email protected]>> wrote: > 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. > > That is my understanding as well. > > > 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 > > connection timeout > session timeout doesn't seem to be useful indeed. > > But connection timeout < session timeout seems to be erroneous as well. The > ZK API will spend seessionTimeout to go through all the nodes. So if the > connectionTimeout is smaller, we may only try to connect to a subset of those > nodes. I have no idea when that would be a good idea. > > As far as I understand, connectionTimeout has to be equal to sessionTimeout. > > > > > On Wed, Nov 2, 2016 at 9:03 AM, Benjamin Jaton <[email protected] > <mailto:[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 > > <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 > >
