> I can't think of a use case where that's useful. Have a look at StandardConnectionHandlingPolicy.callWithRetry(). It waits for a positive connection or until the connection timeout has elapsed. But, IT CALLS THE METHOD ANYWAY. There are many reasons to have a small connection timeout. You could even do your own waitUntilConnected, close the Curator handle on failure and try again increasing the likelihood that ZooKeeper would try another server. It’s a tool in a toolbox. Use it how you like.
-Jordan > On Nov 2, 2016, at 11:43 AM, Benjamin Jaton <[email protected]> wrote: > > Well I can do that, but I would probably recommend using connectionTimeout = > sessionTimeout. > > By default Curator uses: > private static final int DEFAULT_SESSION_TIMEOUT_MS = > Integer.getInteger("curator-default-session-timeout", 60 * 1000); > private static final int DEFAULT_CONNECTION_TIMEOUT_MS = > Integer.getInteger("curator-default-connection-timeout", 15 * 1000); > So by default Curator will only check the first node. > > I can't think of a use case where that's useful. > > Regardless I can write something after I do more tests on this. > > > > > On Wed, Nov 2, 2016 at 9:10 AM, Jordan Zimmerman <[email protected] > <mailto:[email protected]>> wrote: > That’s correct Benjamin. As Curator wraps the library-provided ZooKeeper > class there’s nothing Curator can do about this. I’ll try to write a Tech > Note about this when I can. If you don’t mind, Benjamin, maybe you could > write it? > > https://cwiki.apache.org/confluence/display/CURATOR/Tech+Notes > <https://cwiki.apache.org/confluence/display/CURATOR/Tech+Notes> > > -Jordan > > >> On Nov 2, 2016, at 11:08 AM, Benjamin Jaton <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> 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. >> >> How can this timeout after 20 secs, if the connection timeout is 10 seconds? >> Also, >> >> Curator's connectionTimeout is to be understood as connection to the whole >> ensemble, not individual node. >> >> How long do you think the ZooKeeper API will wait for a connection before >> trying the next node? >> The answer is sessionTimeout / #nodes = 60 / 3 = 20 seconds. >> >> 0 sec - try 1st node >> 20 sec - try 2nd node >> 40 sec - try 3rd node >> >> Now if Curator has a cap at 10 seconds, it won't wait for the ZK API to >> reach the other 2 nodes. >> >> Hope that's clearer. >> >> Benjamin >> >> >> So Curator would fail to connect yet the ensemble is available >> >> Can you explain the above statement then? As for my understanding, curator >> will try all Zookeeper nodes until it connects to an up and running >> zookeeper server or until the connection timeout. >> >> -Imesha >> >> On 2 November 2016 at 10:45, Cameron McKenzie <[email protected] >> <mailto:[email protected]>> wrote: >> Session timeout is a Zookeeper concept. It's just the amount of time (in MS) >> that a client session can be idle for before the Zookeeper server times it >> out. A heart beat keeps the session alive, so the session will only time >> out due to network issues. >> >> The connection timeout is a Curator concept. Jordan described its use in >> this thread. Basically, it just defines how long Curator will wait for a >> connection to be established to Zookeeper before giving up and trying again. >> >> On Wed, Nov 2, 2016 at 4:00 PM, Imesha Sudasingha <[email protected] >> <mailto:[email protected]>> wrote: >> Hello all, >> >> I was going through this thread and found out I too need a clear explanation >> on "what is connectionTimeout and sessionTimeout". Even though you have >> discussed a lot about it(which I have read), still I'm not getting a clear >> picture. Can someone elaborate on the it? And give a clear view of those 2 >> parameters and what they are for? >> >> Thanks! >> >> Regards, >> Imesha Sudasingha >> >> >> On Nov 2, 2016 4:26 AM, "Jordan Zimmerman" <[email protected] >> <mailto:[email protected]>> wrote: >> >>> so if we use a connectionTimeout smaller than sessionTimeout, we may fail >>> before having tried all the nodes. >> >> That’s correct and up to you. That’s why these are configurable options. Use >> values that make sense for your applications. >> >> -Jordan >> >> >> >> >> >> >> >> -- >> Imesha Sudasingha >> Undergraduate of Department of Computer Science and Engineering, >> University of Moratuwa. >> +94717086160 <tel:%2B94717086160> >> View in Linkedin <https://lk.linkedin.com/in/imeshasudasingha> > >
