Gee - I don’t know what else to say :D It’s really not clear from this thread? Honestly, I don’t know how to say it any clearer. Anyone else? Again, here’s what I wrote earlier today:
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. -Jordan > On Nov 2, 2016, at 12:00 AM, Imesha Sudasingha <[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 > > >
