[
https://issues.apache.org/jira/browse/ZOOKEEPER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191711#comment-13191711
]
Ted Dunning commented on ZOOKEEPER-366:
---------------------------------------
History repeats itself. I have patches on ZOOKEEPER-1366 that use nanoTime to
avoid these problems, but don't include the limit on number of expirations per
tick.
I suggest that we mark this issue as a duplicate of that issue and apply that
patch since it is up to date. Any objections?
> 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
> Components: quorum, server
> Reporter: Benjamin Reed
> Assignee: Benjamin Reed
> Fix For: 3.5.0
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
