[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308985#comment-14308985 ] Hudson commented on ZOOKEEPER-1366: --- FAILURE: Integrated in ZooKeeper-trunk #2587 (See [https://builds.apache.org/job/ZooKeeper-trunk/2587/]) ZOOKEEPER-1366 Zookeeper should be tolerant of clock adjustments (Hongchao Deng via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1657745) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/ClientCnxnSocket.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/Login.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/Shell.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/ZKUtil.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/common/Time.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ConnectionBean.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ExpiryQueue.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/RateLogger.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/Request.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ServerStats.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/SessionTrackerImpl.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/WorkerService.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ZKDatabase.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/FastLeaderElection.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/Follower.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/Leader.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LearnerSnapshotThrottler.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java * /zookeeper/trunk/src/java/systest/org/apache/zookeeper/test/system/GenerateLoad.java * /zookeeper/trunk/src/java/systest/org/apache/zookeeper/test/system/InstanceManager.java * /zookeeper/trunk/src/java/systest/org/apache/zookeeper/test/system/SimpleSysTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/common/TimeTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ClientBase.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ClientHammerTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/CnxManagerTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/LoadFromLogTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ReadOnlyModeTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/TestHammer.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ZooKeeperTestClient.java > 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: Hongchao Deng >Priority: Critical > Fix For: 3.5.1, 3.6.0 > > 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-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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308687#comment-14308687 ] Rakesh R commented on ZOOKEEPER-1366: - Thank you [~hdeng], all others for quickly fixing this issue. [~michim] there is one subtask in OPEN state for changing C library part - ZOOKEEPER-1626. I feel its good to keep the parent jira in open state until all the sub-tasks is completed. Either we can re-open this parent jira task or will move the sub-task ZOOKEEPER-1626 to a main jira and work on until it is closed. Whats your opinion? > 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: Hongchao Deng >Priority: Critical > Fix For: 3.5.1, 3.6.0 > > 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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308633#comment-14308633 ] Michi Mutsuzaki commented on ZOOKEEPER-1366: +1 Thanks Hongchao! > 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: Hongchao Deng >Priority: Critical > Fix For: 3.5.1, 3.6.0 > > 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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308524#comment-14308524 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Hi [~michim]. Thanks for your attention to the issue. Patch on RB: https://reviews.apache.org/r/30677/diff/ You are cordially welcome to review and give feedback. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307758#comment-14307758 ] Rakesh R commented on ZOOKEEPER-1366: - +1 latest patch looks good to me > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307701#comment-14307701 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696794/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2512//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2512//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2512//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307674#comment-14307674 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Hi [~rakeshr]. Can you help take a review too? https://reviews.apache.org/r/30677/diff/G > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307646#comment-14307646 ] Marshall McMullen commented on ZOOKEEPER-1366: -- Latest version looks great to me. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307623#comment-14307623 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Thanks [~marshall] for the comments. Fix it and upload a new patch. I messed up with previous RB. So opened a new one: https://reviews.apache.org/r/30677/diff/ > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307477#comment-14307477 ] Marshall McMullen commented on ZOOKEEPER-1366: -- I reviewed this on review board as well. Only a couple of minor comments. Overall looks very very good. +1. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306389#comment-14306389 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696625/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2509//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2509//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2509//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306264#comment-14306264 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696597/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2508//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2508//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2508//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306132#comment-14306132 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696567/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2507//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2507//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2507//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306017#comment-14306017 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Addressed Rakesh's comments and uploaded a new patch. Great to have you to review, thanks [~marshall]! > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304763#comment-14304763 ] Marshall McMullen commented on ZOOKEEPER-1366: -- [~hdeng] - I will be happy to help review this tomorrow. It's important to us to pick up this fix as well so I'd love to see this rolled into the 3.5 release. I'll make sure to review this and add comments to the review tomorrow. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14304731#comment-14304731 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696393/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2506//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2506//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2506//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303795#comment-14303795 ] Hongchao Deng commented on ZOOKEEPER-1366: -- I have also tested with Ted's command line program mentioned above. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303791#comment-14303791 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Please help review the code and give feedback. Thanks! > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303789#comment-14303789 ] Hongchao Deng commented on ZOOKEEPER-1366: -- Hi, I have uploaded my patch to review board: https://reviews.apache.org/r/30573/ Most of the code are based on previous patch. I made the changes to the System.currentTimeMillis() added after previous patch and checked them out with Patrick. Added some docs. And renamed all System.currentTimeMillis() to Time.currentWallTime() to make it explicit. The tests are irrelevant. Though one is added by me and it's really flaky now... I will try to fix it at the Netty part. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14303761#comment-14303761 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12696230/ZOOKEEPER-1366.patch against trunk revision 1656167. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 46 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2505//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2505//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2505//console This message is automatically generated. > 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: Hongchao Deng >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-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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302775#comment-14302775 ] Rakesh R commented on ZOOKEEPER-1366: - +1 pushing to 3.5 branch. I'm happy to help you in reviews and push this in. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14302095#comment-14302095 ] Hongchao Deng commented on ZOOKEEPER-1366: -- I realized there is still a few calls of currentTimeMillis() after applying the patch. The patch is almost done. I would like to investigate those calls and come down with a new patch. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301972#comment-14301972 ] Flavio Junqueira commented on ZOOKEEPER-1366: - Since this jira has been sitting here for so long, a couple of weeks won't make much of a difference. But sure, let's keep it open for others to pick it up until you're free, and thanks for volunteering in any case, [~marshall]. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301887#comment-14301887 ] Marshall McMullen commented on ZOOKEEPER-1366: -- [~fpj] [~phunt] - I would be happy to take the lead on this Jira as it's very important to us internally. My current week is rather swamped with other things, but I think I'd be able to pick this up after things quiet down here in the next week or so. If someone else has more time and wants to take this before I have the opportunity they are welcome to. Otherwise in the next week or so when things quiet down I'll look at taking this Jira. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14301589#comment-14301589 ] Flavio Junqueira commented on ZOOKEEPER-1366: - This is a pretty long jira, and it is unfortunate that it has been cooking for so long. Perhaps someone else could pick it up and finish the patch, since Ted is already burned out (understandably)? > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300877#comment-14300877 ] Rakesh R commented on ZOOKEEPER-1366: - Thanks again [~tdunning] for the reply and the effort you had put so far. I feel this is important, will see the opinion from others as well. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300879#comment-14300879 ] Rakesh R commented on ZOOKEEPER-1366: - Thanks again [~tdunning] for the reply and the effort you had put so far. I feel this is important, will see the opinion from others as well. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300878#comment-14300878 ] Rakesh R commented on ZOOKEEPER-1366: - Thanks again [~tdunning] for the reply and the effort you had put so far. I feel this is important, will see the opinion from others as well. > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14300826#comment-14300826 ] Ted Dunning commented on ZOOKEEPER-1366: Actually, no. I hadn't considered them. In fact, I had pretty much given up on this patch since it was ignored for two years after it caused a major P1 outage at multiple sites. I figured it was just me that considered it important enough to try to fix. And at this point, I don't have time to update the patch. Check with Patrick or Michi. (I am only vaguely sorry about being snippy here. This was an egregious case of ignoring a fairly valid patch on an important issue). > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14299708#comment-14299708 ] Rakesh R commented on ZOOKEEPER-1366: - Thanks [~tdunning] for the patch, have you had a chance to consider the last batch of comments? > 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)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075064#comment-14075064 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12657908/ZOOKEEPER-1366.patch against trunk revision 1613474. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 49 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2237//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2237//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2237//console This message is automatically generated. > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075021#comment-14075021 ] Raul Gutierrez Segales commented on ZOOKEEPER-1366: --- Some nits: Lines too long (> 80): {noformat} +/** + * Returns time in milliseconds as does System.currentTimeMillis(), but uses elapsed time from an arbitrary epoch + * more like System.nanoTime(). The difference is that if somebody changes the system clock, Time.currentElapsedTime + * will change but nanoTime won't. On the other hand, all of ZK assumes that time is measured in milliseconds. + * @return The time in milliseconds from some arbitrary point in time. + */ {noformat} Might as well put the comment outside of the method: {noformat} long getTime() { +// This method doesn't use Time.currentElapsedTime() because it's used +// to set znode ctime and mtime. {noformat} Long lines: {noformat} +Assert.assertEquals(Time.currentElapsedTime() - nt0, System.currentTimeMillis() - mt0, 10); {noformat} {noformat} + * While running this, try changing the clock forward using something like [date -s "+1hour"]. + * On a zookeeper that uses currentTimeMillis(), this will cause all ephemerals to be deleted + * due to session expiration. With the use of nanoTime instead, zookeeper is unphased. + * + * @param args Not used. + * @throws Exception Not really. In fact, the only exceptions are InterruptedException, KeeperException {noformat} ditto: {noformat} +System.out.printf("%d\t%s\n", discrepancy(), zk.exists("/ephemeral", watchCount.get() == 0 ? createWatcher() : null) != null); {noformat} Consistent spaces around + operator: {noformat} +LOG.info("Elapsed "+(end - start) + " ms: " + message); {noformat} > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14074676#comment-14074676 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12641585/ZOOKEEPER-1366.patch against trunk revision 1613474. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 48 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2236//console This message is automatically generated. > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979040#comment-13979040 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12641585/ZOOKEEPER-1366.patch against trunk revision 1588584. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 48 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2057//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2057//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2057//console This message is automatically generated. > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979013#comment-13979013 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12641585/ZOOKEEPER-1366.patch against trunk revision 1588584. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 48 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2056//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2056//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2056//console This message is automatically generated. > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978977#comment-13978977 ] Michi Mutsuzaki commented on ZOOKEEPER-1366: ... that's what I get for not using 'svn patch' command. Thanks for catching Raul. I'll re-upload the patch to reviewboard. > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978968#comment-13978968 ] Raul Gutierrez Segales commented on ZOOKEEPER-1366: --- [~michim]: I think the RB is missing some new files (i.e.: Time.java), no? > 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13978959#comment-13978959 ] Michi Mutsuzaki commented on ZOOKEEPER-1366: review: https://reviews.apache.org/r/20635/ We should fix this in 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.0 > > 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-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.2#6252)
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759315#comment-13759315 ] Asad Saeed commented on ZOOKEEPER-1366: --- A few issues with this patch. It is much broader than it should be. In Login.java: 2 timesources are being utilized and incorrectly compared: Time.currentElapsedTime is not compatible with the (KerberosTicket).getEndTime which will return the expiry based on the system time. The 2 time values are compared in the following block -- if (nextRefresh > expiry) { LOG.error("next refresh: " + nextRefreshDate + " is later than expiry " + expiryDate + ". This may indicate a clock skew problem. Check that this host and the KDC's " + "hosts' clocks are in sync. Exiting refresh thread."); return; -- ZookeeperServer::getTime: Utilization of Time.currentElapsedTime here will lead to unusable timestamps for the mtime and ctime for nodes. DataTree::processTxn uses the TxnHeader.time to populate the Stat structure. TxnHeader.time is assigned by PrepRequestProcessor::pRequest2Txn using ZookeeperServer.getTime. > 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 > Fix For: 3.5.0 > > 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-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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757489#comment-13757489 ] Ted Dunning commented on ZOOKEEPER-1366: Why do you say this? What scenario would cause a breakage? > 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 > Fix For: 3.5.0 > > 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-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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757211#comment-13757211 ] Asad Saeed commented on ZOOKEEPER-1366: --- These patches will break Kerberos login. It mixes monotonic and actual time. > 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 > Fix For: 3.5.0 > > 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-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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729942#comment-13729942 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12596213/zookeeper-3.4.5-ZK1366-SC01.patch against trunk revision 1503101. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 52 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1527//console This message is automatically generated. > 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 > Fix For: 3.5.0 > > 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-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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710776#comment-13710776 ] Hangjun Ye commented on ZOOKEEPER-1366: --- Not committed yet? > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586081#comment-13586081 ] Hadoop QA commented on ZOOKEEPER-1366: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12570508/ZOOKEEPER-1366.patch against trunk revision 1448007. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 49 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1408//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1408//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1408//console This message is automatically generated. > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584559#comment-13584559 ] Marshall McMullen commented on ZOOKEEPER-1366: -- My latest patch fixes all the unit test failures. My prior two statements still apply: > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584560#comment-13584560 ] Marshall McMullen commented on ZOOKEEPER-1366: -- My prior two caveats still apply: (2) I did NOT go through and find other uses of System.currentTimeMillis to see if they should be converted to Time.currentElapsedTime(). I think someone more knowledgeable should look these over with a fine tooth comb. (3) Ted's original patch made changes to SessionTrackerImpl.java but those parts of that file that were originally patched don't seem to be present anymore. It looks to me like that code was moved into ExpiryQueue.java. I'd really like some to take a close look at that as well. Any assistance with these three issues is extremely appreciated!! > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584557#comment-13584557 ] Hadoop QA commented on ZOOKEEPER-1366: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12570508/ZOOKEEPER-1366.patch against trunk revision 1448007. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 49 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1405//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1405//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1405//console This message is automatically generated. > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584031#comment-13584031 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12570427/ZOOKEEPER-1366.patch against trunk revision 1448007. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 49 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. -1 javac. The patch appears to cause tar ant target to fail. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1404//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1404//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1404//console This message is automatically generated. > 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 > Fix For: 3.5.0 > > 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 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583970#comment-13583970 ] Hadoop QA commented on ZOOKEEPER-1366: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12570423/ZOOKEEPER-1366.patch against trunk revision 1448007. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 49 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1403//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1403//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1403//console This message is automatically generated. > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575664#comment-13575664 ] Benjamin Reed commented on ZOOKEEPER-1366: -- i was just reviewing this issue and reading my comments that i had recently made. and they sounded like me but i couldn't remember making them last month. then i realized that i made them in 2012!!! we really need to get this patch in. is someone working on it? > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559003#comment-13559003 ] Colin Patrick McCabe commented on ZOOKEEPER-1366: - bq. I think there are changes in the C client that should be made as well to make it more resilent to clock adjustments as well. Doesn't look like any of those were accounted for under this patch. I filed ZOOKEEPER-1626 to deal with the C client changes. > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500520#comment-13500520 ] Ted Dunning commented on ZOOKEEPER-1366: This patch never got committed. It should have been committed long ago. I am happy to resurrect it. Which branches should I generate patches for? > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203348#comment-13203348 ] Ted Dunning commented on ZOOKEEPER-1366: On the off topic of mocking, I was just able to mock System.nanoTime directly using jmockit. Very easy to do. See https://github.com/tdunning/storm-counts/blob/master/src/test/java/com/mapr/storm/Fake.java especially Fake.clock near the bottom. Fake.clock() returns an object that adjusts the value that is returned by System.nanoTime(). I haven't verified that the effect goes away at the end of the test, but jmockit usually handles that correctly. > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13203309#comment-13203309 ] Benjamin Reed commented on ZOOKEEPER-1366: -- agreed. i think also that you can still mock a static api if you provide a method and interface to allow the implementation to get the time from a user provided object. but again that is a different issue. for now i would really really like to get this in asap. it's a shame that it missed the next release since this is a real problem that we have a fix for. even without the C client, the big problem is what happens at the server with the session timeouts and this patch fixes that problem. > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195026#comment-13195026 ] Mahadev konar commented on ZOOKEEPER-1366: -- Pat/Ben, I think the issue here is the api with Clock. The static api is one that ruins mocking in it. In Hadoop we make sure we pass around the same clock object when creating all the sub sequent objects (the constructs in MR next gen are more DI compliant). We could try doing that here but again I think its a bit of an effort (should be manual work). But as Henry/Camille mentioned we could do that in another jira. I think thats the right solution instead of creating another layer which hides the longs (as Pat suggested). > 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 > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194300#comment-13194300 ] Patrick Hunt commented on ZOOKEEPER-1366: - Here's an example from Hadoop, specifically to enable what i'm talking about - testability: org/apache/hadoop/mapred/Clock.java {noformat} /** * A clock class - can be mocked out for testing. */ class Clock { {noformat} > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194296#comment-13194296 ] Patrick Hunt commented on ZOOKEEPER-1366: - Hi Ben: bq. i don't like that idea. why not? it would make it explicit and keep this from happening again. (one would hope) Similar to Date, except in this case we're capturing the concept of elapsed time. It seems like it might also make things more testable (the impl could be mucked with, mocked, etc...). > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194251#comment-13194251 ] Ted Dunning commented on ZOOKEEPER-1366: I can put another method in Time that is the same as currentTimeMillis, but which does the time skew thing (sounds like Rocky Horror to me) > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194248#comment-13194248 ] Benjamin Reed commented on ZOOKEEPER-1366: -- for some reason the review board comments didn't come through, but they are on review board. i think Login.java should all be based on wall time since i think that is what kerberos is based on. perhaps eugene can comment on this. in ZooKeeperServer.java getTime() should return the wall time since that is used for the mtime. in GenerateLoad.java when we print the timestamp we probably should be doing wall time, but since we don't format it, it probably doesn't matter much. in LoadFromLogTest.java when we do datatree ops, usually the second to the last parameter is the wall time. you missed one change to elapsed time in the ReadOnlyModeTest.java one file that isn't in the patch that we need to fix is ServerCnxn.java. i think lastResponseTime should have a comment to say that it is the system time and we can make getLastResponseTime() return the wall time using "return System.currentMillis() - (Time.currentElapsedTime() - lastResponseTime);" after crawling through everything, i think it would be nice if Time also had Time.currentWallTime() that did System.currentMillis(). that way if we saw an instance of System.currentMillis() in the code it would be a flag that the use should be reviewed. oh and we should probably create a jira to fix the C client. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194231#comment-13194231 ] jirapos...@reviews.apache.org commented on ZOOKEEPER-1366: -- --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3648/ --- Review request for zookeeper. Summary --- ZOOKEEPER-1366. Zookeeper should be tolerant of clock adjustments This addresses bug ZOOKEEPER-1366. https://issues.apache.org/jira/browse/ZOOKEEPER-1366 Diffs - src/java/main/org/apache/zookeeper/ClientCnxn.java 6c25e40 src/java/main/org/apache/zookeeper/ClientCnxnSocket.java 269f8e8 src/java/main/org/apache/zookeeper/Login.java 6d2a38c src/java/main/org/apache/zookeeper/Shell.java f2c899a src/java/main/org/apache/zookeeper/ZKUtil.java 4713a08 src/java/main/org/apache/zookeeper/common/Time.java PRE-CREATION src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java 9721f7c src/java/main/org/apache/zookeeper/server/Request.java c6a2249 src/java/main/org/apache/zookeeper/server/ServerStats.java acbc97c src/java/main/org/apache/zookeeper/server/SessionTrackerImpl.java cbae57a src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java 14f8c8f src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java 8ba12c5 src/java/main/org/apache/zookeeper/server/quorum/FastLeaderElection.java 473d01e src/java/main/org/apache/zookeeper/server/quorum/Follower.java 29ef3f9 src/java/main/org/apache/zookeeper/server/quorum/Leader.java 27a5d20 src/java/systest/org/apache/zookeeper/test/system/GenerateLoad.java 57d0dcb src/java/systest/org/apache/zookeeper/test/system/InstanceManager.java 809fa48 src/java/systest/org/apache/zookeeper/test/system/SimpleSysTest.java 9cdf4d9 src/java/test/org/apache/zookeeper/common/TimeTest.java PRE-CREATION src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java c2cfd7a src/java/test/org/apache/zookeeper/test/ClientBase.java 02638a1 src/java/test/org/apache/zookeeper/test/ClientHammerTest.java b807dbb src/java/test/org/apache/zookeeper/test/CnxManagerTest.java fd59403 src/java/test/org/apache/zookeeper/test/LoadFromLogTest.java 8e0b0eb src/java/test/org/apache/zookeeper/test/ReadOnlyModeTest.java c705a7b src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java 1fed88a src/java/test/org/apache/zookeeper/test/TestHammer.java 09a678b src/java/test/org/apache/zookeeper/test/ZooKeeperTestClient.java cc82c87 src/recipes/queue/src/c/tests/Util.cc 26a9a09 Diff: https://reviews.apache.org/r/3648/diff Testing --- Thanks, Benjamin > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194005#comment-13194005 ] Benjamin Reed commented on ZOOKEEPER-1366: -- i don't like that idea. if we have to go that direction i would much rather use Date in cases where it will be human readable, but i'm not really a fan of that either. there are very few places that we need System.currentTimeMillis() lets just fix those. did we just put getLastResponseTime in the connection statistics because we happened to have it or because someone requested it? > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193571#comment-13193571 ] Patrick Hunt commented on ZOOKEEPER-1366: - It seems like Timer/elapsedTime should be wrapped with some abstraction that keeps this problem from happening w/o making it explicit. Rather than passing a long around say, it would instead have a "TimerStart startElapsedTime()" pass TimerStart around, then eventually "timerStart.elapsed()" which returns a long. This would keep us from making the same mistake in other places (well, w/o making it explicit). > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193558#comment-13193558 ] Benjamin Reed commented on ZOOKEEPER-1366: -- i don't think we should commit with TODO's. it shouldn't be hard to go through them before we commit. in the line that pat identified, it is passing the correct thing operationally, but it does mess up the last response time. do we want to add a System.currentTimeMillis() just to get the correct last response time? we could actually convert the time in getLastResponseTime() using System.currentTimeMillis() - (Time.currentElapsedTime()-lastResponseTime), so that the extra call to currentTimeMillis would only happen on getLastResponseTime, which happens very infrequently. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193557#comment-13193557 ] Patrick Hunt commented on ZOOKEEPER-1366: - This issue has been in the code base since day one, a few weeks or even months spent getting it right aren't going to hurt anything. Also given the "devil you know" aspect of this, the fact it's so cross-cutting, i'd push this into trunk and only consider it for backporting into a fix release once it's been well proven. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193540#comment-13193540 ] Ted Dunning commented on ZOOKEEPER-1366: Pat is right that this should not be used as a substitute for elapsed time. I think that the right ways to proceed are to either - mark all of the changes with TODO's that can be removed progressively (risk of not finishing) - do a comprehensive review now Option 1 should only be committed to trunk and only back ported when done. Option 2 delays the commit for an important operational issue. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193482#comment-13193482 ] Patrick Hunt commented on ZOOKEEPER-1366: - I don't think so Ben (on both counts). Has this been reviewed fully? I'm looking at it now for the first time and I notice a pretty serious issue right off the bat. Given the docs say the following for nanotime bq. This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. the following is going to be a major headache: {noformat} cnxn.updateStatsForResponse(request.cxid, request.zxid, lastOp, -request.createTime, System.currentTimeMillis()); +request.createTime, Time.currentElapsedTime()); {noformat} We shouldn't be using nanotime in any place where we display a date/time to a user. (ie ONLY use it to measure elapsed time) I think we should just put this into trunk only. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193471#comment-13193471 ] Benjamin Reed commented on ZOOKEEPER-1366: -- once the @Test annotation is in, i think this is good to go. right? did we decide if this was going to be applied to any branches? > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191917#comment-13191917 ] Patrick Hunt commented on ZOOKEEPER-1366: - Ted - ha I thought the same thing (re #) :-) > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191706#comment-13191706 ] Ted Dunning commented on ZOOKEEPER-1366: @Pat, ZOOKEEPER-366 is essentially the same issue except that the suggested solution is weaker since it doesn't handle the problem of time jumping backwards, nor suggest a method to detect the time jumps. The numerological coincidence on the issue number is quite striking. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191412#comment-13191412 ] Patrick Hunt commented on ZOOKEEPER-1366: - I have similar concerns as Mahadev re stability - this is a big change to introduce into a fix release. I'd rather see it go into trunk. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191409#comment-13191409 ] Patrick Hunt commented on ZOOKEEPER-1366: - @Ted my comment has nothing to do with Henry's suggestion re refactoring - I was pointing out that there is a similar JIRA to this that should probably be closed out - please see ZOOKEEPER-366 > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191403#comment-13191403 ] Ted Dunning commented on ZOOKEEPER-1366: @Mahadev, I will produce patches for several versions as well as pre-built tar files. This will include trunk, 3.4, 3.3.3 and 3.3.2. The rate at which we encounter this kind of problem even at facilities that are pretty sophisticated says to me that even if this isn't strictly a bug, then it seriously decreases the probability that ZK will function well averaged over all plausible users. Developers and users then think ZK is seriously buggy. As such, we view this internally as a required fix that we will be deploying as a patch on our current production version of ZK. Whether the ZK community views it that way relative to 3.4 is an entirely separate question, of course. @Pat, @Henry, I really do think that doing the simple small thing (this patch) is important without waiting on the resolution of the larger more comprehensive fix (fixing time management in general). Thanks for your efforts in that vein. @Camille, I will have a slightly revised set of patches by tonight that fix the @Test issue. I also think that mocking was not at all the point of this patch. The only way that this makes mocking easier is that we now have a (slightly) more distinctive string to search for but as you point out, that isn't the real issue anyway. Mocking static functions is becoming a more common capability, but I would rather do it right when we do it. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191396#comment-13191396 ] Camille Fournier commented on ZOOKEEPER-1366: - @Henry: I am fine with doing it as a separate ticket. I do think it's pretty trivial to rework this and get ourselves far down the road with a non-static impl, and not sure that we need to address Thread.sleep() to get a lot of mileage out of the solution. But I don't think I'll have time to rework this patch to do that so might as well do it in a separate ticket if Ted doesn't want to worry about that. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191384#comment-13191384 ] Mahadev konar commented on ZOOKEEPER-1366: -- @Ted, Seems like a good change, only one issue I see here. I'd like this to go into trunk and not into 3.4 unless its really a bug. I think 3.4 will take sometime to stabilize and would really like to avoid big changes in 3.4. Thoughts? > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191376#comment-13191376 ] Henry Robinson commented on ZOOKEEPER-1366: --- My feeling is that Ted's fixing a legitimate issue here, so we shouldn't hold up the patch for a separate effort. Reworking how we deal with time is going to be a big effort (Thread.sleep really does complicate things, plus there's the question of how to actually inject a mock clock - as you say, such method calls would need to be non-static but then we need to figure out how to get the right implementation behind those methods). This patch doesn't get in the way of doing a better job with time, and gives us the beginnings of a nice integration point to mock clocks out. So I'll file a separate JIRA to track being able to change our clock implementation, and we can evaluate this on its own merits (might be nice to run a soak test for a few hours here to make sure that there are no weird edge cases that somehow got broken). Sound good? > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191371#comment-13191371 ] Patrick Hunt commented on ZOOKEEPER-1366: - See ZOOKEEPER-366 for a previous discussion/solution for this issue. Would be good to close that one out if this is addressing the issue more directly. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190837#comment-13190837 ] Camille Fournier commented on ZOOKEEPER-1366: - So in general, I think this is a good patch and a very good thing for us to do. But I feel like Henry's comment is most interesting: {quote} The nice thing is that this is a small step towards a properly mockable time API in ZK, which would a) make tests much faster and b) make tests much more deterministic. There's a way to go still because of Thread.sleep and other complications, but this is a good first step. {quote} We really aren't doing all that much towards that end by replacing one static method call with another. You still can't mock that in mockito. So the only question I have here is, if we're going to touch all those places anyway, should we just be creating an actual thin object that wraps "time" and use non-static methods on that object to make these calls, in order to allow more mocking of timing issues in the future? Or should we save that for another patch? > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190832#comment-13190832 ] Camille Fournier commented on ZOOKEEPER-1366: - The test in TimerTest is missing the @Test annotation which I presume is an oversight. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189573#comment-13189573 ] Ted Dunning commented on ZOOKEEPER-1366: For the test, I have created a branch in my github fork of zookeeper called timer-test and one called ZK-1366. Both have the test case below but only ZK-1366 has the fix. The test procedure is to do this in one window: {code} git checkout timer-test ant clean compile-test echo build/test/lib/*.jar build/lib/*.jar build/classes build/test/classes | sed -e 's/ /:/g' > cp java -cp $(cat cp) org.apache.zookeeper.common.TimeTest | tee log-without-patch {code} After the test program starts, in a second window, do these commands separated by a second or three {code} date -s '+1hour' date -s '-1hour' {code} This will produce output that looks like this {code} ubuntu@ip-10-113-27-85:~/zookeeper$ java -cp $(cat cp) org.apache.zookeeper.common.TimeTest | tee log-without-patch 1 log4j:WARN No appenders could be found for logger (org.apache.zookeeper.PortAssignment). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. after construct server start client 1 true 1 true 0 true 1 true 360 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Disconnected type:None path:null 361 event = WatchedEvent state:Expired type:None path:null 361 event = WatchedEvent state:Expired type:None path:null 361 event = WatchedEvent state:Expired type:None path:null 361 event = WatchedEvent state:Expired type:None path:null 361 event = WatchedEvent state:Expired type:None path:null {code} The number is the time discrepancy between the system clock and the elapsed time from start of the program. With the patch, {code} git checkout ZK-1366 ant clean compile-test echo build/test/lib/*.jar build/lib/*.jar build/classes build/test/classes | sed -e 's/ /:/g' > cp java -cp $(cat cp) org.apache.zookeeper.common.TimeTest | tee log-with-patch {code} The output looks like this: {code} ubuntu@ip-10-113-27-85:~/zookeeper$ less log-with-patch 1 after construct server start client 0 true 0 true 1 true 0 true 1 true 0 true 0 true 360 true 360 true 360 true 360 true 0 true 0 true 0 true 0 true -360true -361true -360true -1 true -1 true -1 true -1 true {code} As you can see, the timing discrepancy goes up and down but the ephemerals never disappear. I will update the patch shortly to match the ZK-1366 branch on my github clone. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189560#comment-13189560 ] Henry Robinson commented on ZOOKEEPER-1366: --- Oh, and my main concern here was non-monotonicity across cores, but [this page|http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html] alleviates that concern for modern Linux kernels: {quote} 1. Is clock_gettime(CLOCK_REALTIME) consistent across all processors/cores? >(Does arch matter? e.g. ppc, arm, x86, amd64, sparc). It *should* or it's considered buggy. However, on x86/x86_64, it is possible to see unsynced or variable freq TSCs cause time inconsistencies. 2.4 kernels really had no protection against this, and early 2.6 kernels didn't do too well here either. As of 2.6.18 and up the logic for detecting this is better and we'll usually fall back to a safe clocksource. ppc always has a synced timebase, so that shouldn't be an issue. arm, i'm not so familiar with, but i assume they do the right thing (i've not seen many arm bugs on this issue). {quote} > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189557#comment-13189557 ] Henry Robinson commented on ZOOKEEPER-1366: --- The nice thing is that this is a small step towards a properly mockable time API in ZK, which would a) make tests much faster and b) make tests much more deterministic. There's a way to go still because of Thread.sleep and other complications, but this is a good first step. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189543#comment-13189543 ] Ted Dunning commented on ZOOKEEPER-1366: Ben, Regarding the header, I think that RAT can do something like that. Also, I can configure IntelliJ to do the right thing by default (I have that set for Mahout... forgot on ZK). Regarding testing, I have been unable to come up with a substantive unit test. It is trivial to test the Time.currentElapsedTime method, but that provides little information. A manual test is easy. Start a client that creates an ephemeral. Set system time +1hour. Note that ephemeral vanishes and client goes away in shame because it's session is marked as expired. Now repeat with patch. I will do the test and attach a transcript. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189538#comment-13189538 ] Benjamin Reed commented on ZOOKEEPER-1366: -- good catch zhihong! i wish hudson would check that for us... > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.patch, ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189535#comment-13189535 ] Ted Dunning commented on ZOOKEEPER-1366: Yes. The correct response on my part is "Ooops". On Thu, Jan 19, 2012 at 11:54 PM, Zhihong Yu (Commented) (JIRA) < > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189505#comment-13189505 ] Zhihong Yu commented on ZOOKEEPER-1366: --- The following would be replaced with Apache License header, I assume: {code} +/** + * Created by IntelliJ IDEA. + * User: tdunning {code} > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189488#comment-13189488 ] Benjamin Reed commented on ZOOKEEPER-1366: -- +1 nice patch. i vaguely remember a duplicate issue on this. i think ted is right, this is about how we detect time. any idea how we can test this ted? :) > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189336#comment-13189336 ] Ted Dunning commented on ZOOKEEPER-1366: Yes. You are correct. Both bugs mention timers. That doesn't make them all that related. The recent ZOOKEEPER-1239 uses timers as well, but it isn't really all that related to either ZOOKEEPER-702 or this issue. As I read it ZOOKEEPER-702 is about failure detection. This bug is about making zookeeper work correct even when the system clock is advanced or retarded. It has nothing to do with failure detection and ZOOKEEPER-702 has really nothing to do with this issue. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189284#comment-13189284 ] Flavio Junqueira commented on ZOOKEEPER-1366: - You're talking about timers in your description, and we use timers for failure detection. The main problem is getting that patch in, there hasn't been enough agreement to get it committed. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189265#comment-13189265 ] Ted Dunning commented on ZOOKEEPER-1366: I don't think so. This change makes ZK work better. It doesn't detect failures. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189038#comment-13189038 ] Flavio Junqueira commented on ZOOKEEPER-1366: - Hi Ted, I was wondering if this change fits into the framework of ZOOKEEPER-702. > 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 > Fix For: 3.4.3 > > Attachments: ZOOKEEPER-1366.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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188981#comment-13188981 ] Ted Dunning commented on ZOOKEEPER-1366: The ReadOnlyModeTest failure was an environmental fluke. It passes on Ubuntu and OSX. Patch coming up. > 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 > Fix For: 3.4.3 > > > 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 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
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188974#comment-13188974 ] Ted Dunning commented on ZOOKEEPER-1366: See https://github.com/tdunning/zookeeper for a work in progress. Tests seem good except for ReadOnlyModeTest. That may be failing due to unrelated issues. > 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 > Fix For: 3.4.3 > > > 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 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