curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: What is connectionTimeoutMs?
Date Tue, 01 Nov 2016 22:47:40 GMT
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 <benjamin.jaton@gmail.com> wrote:
> 
> 
> 
> On Tue, Nov 1, 2016 at 3:26 PM, Cameron McKenzie <cammckenzie@apache.org <mailto:cammckenzie@apache.org>>
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 <benjamin.jaton@gmail.com <mailto:benjamin.jaton@gmail.com>>
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
> 
> 


Mime
View raw message