Thanks @Deng. I think I should set maxSessionTimeout rather than increasing the tickTime. The default value of max session timeout is confusing and it took us some time to notice this limitation. I will update the log to print negotiationSessionTimeout rather than the sessionTimeout from client.
On Thu, Aug 28, 2014 at 12:35 PM, Hongchao Deng <[email protected]> wrote: > My understanding is that large session timeout limits scalability of > client numbers. Theoretically speaking, it is possible to increase the > maximum session timeout in your case. > > - Hongchao Deng > > > > Date: Thu, 28 Aug 2014 12:22:52 +0800 > > Subject: Re: Why sessionTimeout is restricted by tickTime > > From: [email protected] > > To: [email protected] > > CC: [email protected] > > > > > By the way, it comes down to a conflict if one ZooKeeper client set > timeout > > as 10 and one client set timeout as 110. The tickTime can't satisfy all. > > > > > > On Thu, Aug 28, 2014 at 11:53 AM, tobe <[email protected]> wrote: > > > > > Refer to the official guide, we know that the negotiationTimeout must > be > > > greater than twice tickTime and smaller than 20 times of tickTime. > > > > > > I know the tickTime should not be too large or even larger than > > > sessionTimeout, or the session will time out all the time. This > limitation > > > is reasonable, but why the sessionTimeout must be smaller than 20 > times of > > > tickTime? > > > > > > The problem happens in our production environment. We share a ZooKeeper > > > cluster for a few HBase cluster. By default, the tickTime is 2s and the > > > sessionTimeout is 30s. It's ok. But now one of our HBase clusters need > to > > > increase the sessionTimeout to 90s because of long time gc. After > updating > > > the sessionTimout in HBase, we have to update the tickTime in > ZooKeeper. > > > And this setting may have an effect on other HBase clusters. > > > > > > So I wonder why ZooKeeper has this limitation. Can anyone explain to > me? > > > >
