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? > >
