Session timeout is negotiated though eh? So if only the clients that need the long GC session expiration time set their client session timeout to MAX_INT, other clients can keep it at a lower number and not have a problem. That's how we have resolved the issue. It does mean that if you have clients writing directly to the ZK client (instead of through a wrapper you provide), you need to encourage people not to use MAX_INT in their default client setup unless they need the long timeout.
C -----Original Message----- From: Patrick Hunt [mailto:[email protected]] Sent: Wednesday, September 14, 2011 1:44 PM To: [email protected]; [email protected] Subject: Re: Impacts of increasing ZooKeeper ticktime On Wed, Sep 14, 2011 at 3:23 AM, Laxman <[email protected]> wrote: > Our customers are recently complaining about zookeeper client session > timeouts. > > When analyzed its found that timeouts are due to heavy GC activity on > Clients. > > So, they wanted to increase the session timeouts to 3 minutes which requires > the ticktime to be increased to atleast 9 seconds. > I assume you've talked to them about fixing their gc issue at some point? Rather than band-aiding it? :-) I don't think you need to touch the tickTime here. See "maxSessionTimeout" here: http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html#sc_advancedConfiguration (hbase has a similar issue, that's why we added this feature initially). Really though they should fix the gc issue - setting the session timeout higher means that their sessions will be expiring only after a much longer time. Any reliance on this - such as for leader election fail-over, will now take much more time. In your example it would take 3 minutes for the other clients to notice when a client with the particular session has become unavailable. Perhaps it doesn't matter in your use case, but you are now likely to get complains about ZK not being responsive. ;-) Regards, Patrick
