[ https://issues.apache.org/jira/browse/ZOOKEEPER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Reed updated ZOOKEEPER-366: ------------------------------------ Attachment: ZOOKEEPER-366.patch this patch smooths out the effect of a radical time change by always sleeping at least 1/2 tickTime. this means that if we really needed to do a big jump forward, it will take up 1/2 of the jump to converge on the real time. because clients ping for idle times of 1/3 the timeout, there should be few sessions that expire. we could reduce that number, but take even longer to converge if we always sleep at least 3/4 of the tickTime. > Session timeout detection can go wrong if the leader system time changes > ------------------------------------------------------------------------ > > Key: ZOOKEEPER-366 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-366 > Project: Zookeeper > Issue Type: Bug > Reporter: Benjamin Reed > Assignee: Benjamin Reed > Attachments: ZOOKEEPER-366.patch > > > the leader tracks session expirations by calculating when a session will > timeout and then periodically checking to see what needs to be timed out > based on the current time. this works great as long as the leaders clock > progresses at a steady pace. the problem comes when there are big (session > size) changes in clock, by ntp for example. if time gets adjusted forward, > all the sessions could timeout immediately. if time goes backward sessions > that should timeout may take a lot longer to actually expire. > this is really just a leader issue. the easiest way to deal with this is to > have the leader relinquish leadership if it detects a big jump forward in > time. when a new leader gets elected, it will recalculate timeouts of active > sessions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.