It's more than that. If the ZooKeeper connection needs to be re-created (i.e. 
due to session expiration, etc.) then the connection timeout applies once more 
for the new ZooKeeper handle.

-JZ

On Jul 8, 2013, at 9:07 AM, chao chu <[email protected]> wrote:

> I c and thanks for your reply. So, except for the initial 'SysConnected', 
> it's meaningless if connection timeout is larger than session timeout since 
> you will get a SessionExpiredException instead of a ConnectionLossException 
> if it couldn't re-connect to zk before session time out?
> 
> 
> On Mon, Jul 8, 2013 at 11:33 PM, Jordan Zimmerman 
> <[email protected]> wrote:
> In ZooKeeper, you must wait for SysConnected before making any API method 
> calls. Curator handles this internally. The connection timeout defines how 
> long Curator will wait for the SysConnected before throwing 
> ConnectionLossException.
> 
> I hope this helps.
> 
> -Jordan
> 
> On Jul 8, 2013, at 7:52 AM, chao chu <[email protected]> wrote:
> 
>> Hi,
>> 
>> I remembered I had read somewhere that 'connection timeout' in curator has 
>> its own concept and has a separate value from zk's session timeout.
>> 
>> It's not clear from the existing docs/articles/mail threads that what's the 
>> rationale behind this. From the code, it seems that connection timeout is 
>> used to determine (the min value from the two timeouts) when to try to see 
>> if there are updates among the participants of the ensemble?
>> 
>> so 'ConnectionsTimeout' should be normally smaller than session timeout? the 
>> current default values in curator for connection timeout is 15s, and session 
>> timeout is 60s, shall we follow the ratio? Or we just set the value 
>> according to our own experience?
>> 
>> Thanks & Regards,
>> 
>> -- 
>> ChuChao
> 
> 
> 
> 
> -- 
> ChuChao

Reply via email to