curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Jaton <benjamin.ja...@gmail.com>
Subject Re: What is connectionTimeoutMs?
Date Tue, 01 Nov 2016 22:55:21 GMT
The ZK API might take up to <sessionTimeout> to try all the nodes, so if we
use a connectionTimeout smaller than sessionTimeout, we may fail before
having tried all the nodes.

In your example (conenctionTimeout = 10, sessionTimeout = 60, 3 nodes), if
the first node that gets picked up is down it will timeout after 20 sec. So
Curator would fail to connect yet the ensemble is available.

(Note that if you test this locally with TestingServers, you may not
reproduce the issue because the sockets timeout instantly.)

On Tue, Nov 1, 2016 at 3:47 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:

> 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>
> 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>
>> 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/framew
>>> ork/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