[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302605#comment-14302605
 ] 

Patrick Hunt commented on ZOOKEEPER-1366:
-----------------------------------------

It should be ok to have calls to currentTimeMillis - if the call is associated 
with wall clock time (like the time/datestamp of a znode creation). nanoTime 
should be used whenever these is "elapsed time" to consider. E.g. session 
expiration.

Would be great to see someone pick this up - would be a great addition to 3.5.

> Zookeeper should be tolerant of clock adjustments
> -------------------------------------------------
>
>                 Key: ZOOKEEPER-1366
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1366
>             Project: ZooKeeper
>          Issue Type: Bug
>            Reporter: Ted Dunning
>            Assignee: Ted Dunning
>            Priority: Critical
>             Fix For: 3.5.1
>
>         Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, 
> ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, 
> ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, 
> ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, 
> zookeeper-3.4.5-ZK1366-SC01.patch
>
>
> If you want to wreak havoc on a ZK based system just do [date -s "+1hour"] 
> and watch the mayhem as all sessions expire at once.
> This shouldn't happen.  Zookeeper could easily know handle elapsed times as 
> elapsed times rather than as differences between absolute times.  The 
> absolute times are subject to adjustment when the clock is set while a timer 
> is not subject to this problem.  In Java, System.currentTimeMillis() gives 
> you absolute time while System.nanoTime() gives you time based on a timer 
> from an arbitrary epoch.
> I have done this and have been running tests now for some tens of minutes 
> with no failures.  I will set up a test machine to redo the build again on 
> Ubuntu and post a patch here for discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to