[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] [Updated] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Dunning updated ZOOKEEPER-1366: --- Attachment: ZOOKEEPER-1366.patch This patch changes to using relative time everywhere that System.currentTimeMillis was previously used. > 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
Failed: ZOOKEEPER-1365 PreCommit Build #911
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1365 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 148127 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12511078/ZOOKEEPER-1365.patch [exec] against trunk revision 1231809. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] xlUDRHFHCY logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1567: exec returned: 1 Total time: 24 minutes 16 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1365 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1365) Removing a duplicate function and another minor cleanup in QuorumPeer.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13188997#comment-13188997 ] Hadoop QA commented on ZOOKEEPER-1365: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12511078/ZOOKEEPER-1365.patch against trunk revision 1231809. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +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/911//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/911//console This message is automatically generated. > Removing a duplicate function and another minor cleanup in QuorumPeer.java > -- > > Key: ZOOKEEPER-1365 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1365 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Trivial > Attachments: ZOOKEEPER-1365.patch, ZOOKEEPER-1365.patch > > > - getMyId() and getId() in QuorumPeer are doing the same thing > - QuorumPeer.quorumPeers is being read directly from outside QuorumPeer, > although we have the getter QuorumPeers.getView(). > The purpose of this cleanup is to later be able to change more easily the way > QuorumPeer manages its list of peers (to support dynamic changes in this > list). -- 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-1309) Creating a new ZooKeeper client can leak file handles
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189261#comment-13189261
]
Daniel Lord commented on ZOOKEEPER-1309:
Hi Mahadev, the latest patch is from the root check out directory -- the one
that houses both trunk and branches. Is that still not correct? The patch was
for a branch but I can make the same change to the trunk if needed.
We've been running the patch for a while on production and it works nicely.
> Creating a new ZooKeeper client can leak file handles
> -
>
> Key: ZOOKEEPER-1309
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1309
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.3.4
>Reporter: Daniel Lord
>Assignee: Daniel Lord
>Priority: Critical
> Fix For: 3.4.3, 3.5.0
>
> Attachments: zk-1309-1.patch, zk-1309-1.patch, zk-1309-1.patch
>
>
> If there is an IOException thrown by the constructor of ClientCnxn then file
> handles are leaked because of the initialization of the Selector which is
> never closed.
> final Selector selector = Selector.open();
> If there is an abnormal exit from the constructor then the Selector is not
> closed and file handles are leaked. You can easily see this by setting the
> hosts string to garbage ("qwerty", "asdf", etc.) and then try to open a new
> ZooKeeper connection. I've observed the same behavior in production when
> there were DNS issues where the host names of the ensemble can no longer be
> resolved and the application servers quickly run out of handles attempting to
> (re)connect to zookeeper.
--
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=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=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=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-973) bind() could fail on Leader because it does not setReuseAddress on its ServerSocket
[
https://issues.apache.org/jira/browse/ZOOKEEPER-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189491#comment-13189491
]
Benjamin Reed commented on ZOOKEEPER-973:
-
+1 looks good
> bind() could fail on Leader because it does not setReuseAddress on its
> ServerSocket
>
>
> Key: ZOOKEEPER-973
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-973
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.3.2
>Reporter: Vishal Kher
>Assignee: Harsh J
>Priority: Trivial
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-973.patch, ZOOKEEPER-973.patch
>
>
> setReuseAddress(true) should be used below.
> Leader(QuorumPeer self,LeaderZooKeeperServer zk) throws IOException {
> this.self = self;
> try {
> ss = new ServerSocket(self.getQuorumAddress().getPort());
> } catch (BindException e) {
> LOG.error("Couldn't bind to port "
> + self.getQuorumAddress().getPort(), e);
> throw e;
> }
> this.zk=zk;
> }
--
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=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=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] [Updated] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Dunning updated ZOOKEEPER-1366: --- Attachment: ZOOKEEPER-1366.patch Here is an updated patch that fixes the header. > 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-1355) Add zk.updateServerList(newServerList)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189553#comment-13189553 ] Benjamin Reed commented on ZOOKEEPER-1355: -- can you freshen the patch alex? > Add zk.updateServerList(newServerList) > --- > > Key: ZOOKEEPER-1355 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355 > Project: ZooKeeper > Issue Type: New Feature > Components: java client >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1355-ver2.patch, ZOOKEEPER=1355-ver3.patch, > ZOOOKEEPER-1355-test.patch, ZOOOKEEPER-1355-ver1.patch, > ZOOOKEEPER-1355.patch, loadbalancing-more-details.pdf, loadbalancing.pdf > > > When the set of servers changes, we would like to update the server list > stored by clients without restarting the clients. > Moreover, assuming that the number of clients per server is the same (in > expectation) in the old configuration (as guaranteed by the current list > shuffling for example), we would like to re-balance client connections across > the new set of servers in a way that a) the number of clients per server is > the same for all servers (in expectation) and b) there is no > excessive/unnecessary client migration. > It is simple to achieve (a) without (b) - just re-shuffle the new list of > servers at every client. But this would create unnecessary migration, which > we'd like to avoid. > We propose a simple probabilistic migration scheme that achieves (a) and (b) > - each client locally decides whether and where to migrate when the list of > servers changes. The attached document describes the scheme and shows an > evaluation of it in Zookeeper. We also implemented re-balancing through a > consistent-hashing scheme and show a comparison. We derived the probabilistic > migration rules from a simple formula that we can also provide, if someone's > interested in the proof. -- 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=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=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] [Updated] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Dunning updated ZOOKEEPER-1366: --- Attachment: ZOOKEEPER-1366.patch Contains the manual and a trivial automated test. > 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, > 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] [Updated] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Dunning updated ZOOKEEPER-1366: --- Attachment: ZOOKEEPER-1366.patch Updated to current version of 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 > Fix For: 3.4.3 > > Attachments: 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] [Updated] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Dunning updated ZOOKEEPER-1366: --- Attachment: ZOOKEEPER-1366-3.3.3.patch Here is a patch against the 3.3.3 release if desired. This had to be done by restarting the edits since I couldn't come close to cherry picking the final commit to trunk. I was able to cherry pick the test/timer code, however. > 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
ZooKeeper_branch33_solaris - Build # 79 - Failure
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/79/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 76919 lines...] [junit] 2012-01-20 07:27:58,668 - INFO [main:ZooKeeperServer@151] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2 [junit] 2012-01-20 07:27:58,669 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2012-01-20 07:27:58,670 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2/snapshot.0 [junit] 2012-01-20 07:27:58,673 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] 2012-01-20 07:27:58,685 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2012-01-20 07:27:58,687 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:47350 [junit] 2012-01-20 07:27:58,688 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:47350 [junit] 2012-01-20 07:27:58,689 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2012-01-20 07:27:58,694 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:47350 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2012-01-20 07:27:58,696 - INFO [main:ClientBase@385] - STOPPING server [junit] 2012-01-20 07:27:58,697 - INFO [ProcessThread:-1:PrepRequestProcessor@120] - PrepRequestProcessor exited loop! [junit] 2012-01-20 07:27:58,697 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2012-01-20 07:27:58,698 - INFO [main:FinalRequestProcessor@378] - shutdown of request processor complete [junit] 2012-01-20 07:27:58,698 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] ensureOnly:[] [junit] 2012-01-20 07:27:58,700 - INFO [main:ClientBase@378] - STARTING server [junit] 2012-01-20 07:27:58,700 - INFO [main:ZooKeeperServer@151] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2 [junit] 2012-01-20 07:27:58,701 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2012-01-20 07:27:58,702 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test2376833905329399325.junit.dir/version-2/snapshot.b [junit] 2012-01-20 07:27:58,704 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] 2012-01-20 07:27:58,706 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2012-01-20 07:27:58,707 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:47352 [junit] 2012-01-20 07:27:58,707 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:47352 [junit] 2012-01-20 07:27:58,708 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2012-01-20 07:27:58,709 - INFO [Thread-5:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:47352 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2012-01-20 07:27:58,711 - INFO [main:Client
