curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <cammcken...@apache.org>
Subject Re: What is connectionTimeoutMs?
Date Tue, 01 Nov 2016 22:46:03 GMT
Might have to defer to Jordan on this one.

I wonder if it is trying to handle the case where one of the ZK nodes is
dead. Under some circumstances I have seen in the past that the ZK client
did not handle this well, it just got stuck on the dead node and did not
cycle to the others. That's the only think I can think of.

On Wed, Nov 2, 2016 at 9:37 AM, 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