[jira] [Updated] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-1264: - Attachment: ZOOKEEPER-1264unittest.patch i've created a unit test to reproduce the problem since we can test it more directly and deterministicly, but i can't seem to make it happen. i'm attaching my unit test patch just in case you are camille can see what i'm missing. if i understand it, the problem is that we are losing proposals that are received between the NEWLEADER and the UPDATE, but a follower doesn't send out any acks during that time, so it's okay to lose them. am i misunderstanding the problem? FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1264 PreCommit Build #760
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/760/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 142682 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501918/ZOOKEEPER-1264unittest.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [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 failed 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/760//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/760//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/760//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] 6zwdx70T58 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:1576: exec returned: 1 Total time: 19 minutes 21 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1264 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.test.ObserverTest.testObserver Error Message: waiting for server 1 being up Stack Trace: junit.framework.AssertionFailedError: waiting for server 1 being up at org.apache.zookeeper.test.ObserverTest.testObserver(ObserverTest.java:89) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13141972#comment-13141972 ] Hadoop QA commented on ZOOKEEPER-1264: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501918/ZOOKEEPER-1264unittest.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 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/760//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/760//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/760//console This message is automatically generated. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1250) trigger jenkins dummy issue
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-1250: --- Attachment: ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch trigger jenkins dummy issue --- Key: ZOOKEEPER-1250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Trivial Attachments: ZOOKEEPER-1250.145d386_triggerwatches_out.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.c121ec_jute_out_datanode.patch, ZOOKEEPER-1250.d23d30_copyStat_getStat.patch, ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch, ZOOKEEPER-1250_watches_out_datatree.patch Sorry, I don't have my own servers for testing, so I need to upload patches here to run the ZK test suite. -- 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-1250 PreCommit Build #761
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/761/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 156 lines...] [exec] patching file src/java/test/org/apache/zookeeper/server/SerializationPerfTest.java [exec] patching file src/java/test/org/apache/zookeeper/server/quorum/LearnerTest.java [exec] patching file src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java [exec] patching file src/java/test/org/apache/zookeeper/server/quorum/Zab1_0Test.java [exec] patching file src/java/test/org/apache/zookeeper/test/ConnectStringParserTest.java [exec] patching file src/java/test/org/apache/zookeeper/test/DataTreeTest.java [exec] patching file src/java/test/org/apache/zookeeper/test/LoadFromLogTest.java [exec] patching file src/java/test/org/apache/zookeeper/test/MultiTransactionTest.java [exec] patching file src/java/test/org/apache/zookeeper/test/WatcherTest.java [exec] patching file src/java/test/org/apache/zookeeper/test/ZooKeeperQuotaTest.java [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501938/ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 77 new or modified tests. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/761//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] Y3B0Mz0Ka4 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:1576: exec returned: 1 Total time: 39 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1250 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1250) trigger jenkins dummy issue
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142032#comment-13142032 ] Hadoop QA commented on ZOOKEEPER-1250: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501938/ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 77 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/761//console This message is automatically generated. trigger jenkins dummy issue --- Key: ZOOKEEPER-1250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Trivial Attachments: ZOOKEEPER-1250.145d386_triggerwatches_out.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.c121ec_jute_out_datanode.patch, ZOOKEEPER-1250.d23d30_copyStat_getStat.patch, ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch, ZOOKEEPER-1250_watches_out_datatree.patch Sorry, I don't have my own servers for testing, so I need to upload patches here to run the ZK test suite. -- 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
Comment from Martin Fowler
Martin Fowler wrote a comment yesterday on our recent discussion about refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html Regards, Thomas Koch, http://www.koch.ro
ZooKeeper_branch34_solaris - Build # 5 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch34_solaris/5/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 95488 lines...] [junit] 2011-11-02 10:18:09,189 [myid:] - INFO [main:QuorumBase@185] - start QuorumPeer 4 [junit] 2011-11-02 10:18:09,189 [myid:] - WARN [WorkerSender[myid=1]:QuorumCnxManager@368] - Cannot open channel to 3 at election address /127.0.0.1:12229 [junit] java.net.ConnectException: Connection refused [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) [junit] at java.net.Socket.connect(Socket.java:529) [junit] at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:354) [junit] at org.apache.zookeeper.server.quorum.QuorumCnxManager.toSend(QuorumCnxManager.java:327) [junit] at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.process(FastLeaderElection.java:393) [junit] at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.run(FastLeaderElection.java:365) [junit] at java.lang.Thread.run(Thread.java:662) [junit] 2011-11-02 10:18:09,191 [myid:] - INFO [QuorumPeer[myid=3]/0.0.0.0:11224:QuorumPeer@667] - LOOKING [junit] 2011-11-02 10:18:09,190 [myid:] - INFO [main:QuorumPeer@429] - currentEpoch not found! Creating with a reasonable default. This should only happen when you are upgrading your installation [junit] 2011-11-02 10:18:09,191 [myid:] - INFO [QuorumPeer[myid=3]/0.0.0.0:11224:FastLeaderElection@728] - New election. My id = 3, Proposed zxid = 0 [junit] 2011-11-02 10:18:09,192 [myid:] - INFO [/127.0.0.1:12229:QuorumCnxManager$Listener@493] - Received connection request /127.0.0.1:64348 [junit] 2011-11-02 10:18:09,192 [myid:] - INFO [WorkerSender[myid=2]:QuorumCnxManager@190] - Have smaller server identifier, so dropping the connection: (3, 2) [junit] 2011-11-02 10:18:09,191 [myid:] - WARN [WorkerSender[myid=1]:QuorumCnxManager@368] - Cannot open channel to 4 at election address /127.0.0.1:12230 [junit] java.net.ConnectException: Connection refused [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:681) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) at $Proxy25.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:850) at hudson.Launcher$ProcStarter.join(Launcher.java:336) at hudson.tasks.Ant.perform(Ant.java:217) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:693) at hudson.model.Build$RunnerImpl.build(Build.java:178) at hudson.model.Build$RunnerImpl.doRun(Build.java:139) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:459) at hudson.model.Run.run(Run.java:1376) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:732) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1117) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Channel$ReaderThread.run(Channel.java:1093) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280) at java.io.ObjectInputStream$BlockDataInputStream.readUTFBody(ObjectInputStream.java:3018) at java.io.ObjectInputStream$BlockDataInputStream.readUTF(ObjectInputStream.java:2819) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1050) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:616) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java:808) at
[jira] [Commented] (ZOOKEEPER-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142067#comment-13142067 ] Hudson commented on ZOOKEEPER-1246: --- Integrated in ZooKeeper-trunk #1352 (See [https://builds.apache.org/job/ZooKeeper-trunk/1352/]) ZOOKEEPER-1246. Dead code in PrepRequestProcessor catch Exception block (camille) camille : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1196025 Files : * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/PrepRequestProcessorTest.java Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Camille Fournier Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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_trunk_solaris - Build # 35 - Still Failing
See https://builds.apache.org/job/ZooKeeper_trunk_solaris/35/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 126158 lines...] [junit] 2011-11-02 12:01:38,253 [myid:] - INFO [Thread-4:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:41449 (no session established for client) [junit] 2011-11-02 12:01:38,254 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 12:01:38,255 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 12:01:38,255 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 12:01:38,255 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 12:01:38,255 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 12:01:38,255 [myid:] - INFO [main:ClientBase@435] - STOPPING server [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [main:ZooKeeperServer@391] - shutting down [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [main:SessionTrackerImpl@206] - Shutting down [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [main:PrepRequestProcessor@694] - Shutting down [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [main:SyncRequestProcessor@173] - Shutting down [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@134] - PrepRequestProcessor exited loop! [junit] 2011-11-02 12:01:38,256 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2011-11-02 12:01:38,257 [myid:] - INFO [main:FinalRequestProcessor@419] - shutdown of request processor complete [junit] 2011-11-02 12:01:38,257 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 12:01:38,257 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2011-11-02 12:01:38,258 [myid:] - INFO [main:ClientBase@428] - STARTING server [junit] 2011-11-02 12:01:38,258 [myid:] - INFO [main:ZooKeeperServer@143] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_trunk_solaris/trunk/build/test/tmp/test327836352283746501.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_trunk_solaris/trunk/build/test/tmp/test327836352283746501.junit.dir/version-2 [junit] 2011-11-02 12:01:38,259 [myid:] - INFO [main:NIOServerCnxnFactory@110] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-02 12:01:38,259 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_trunk_solaris/trunk/build/test/tmp/test327836352283746501.junit.dir/version-2/snapshot.b [junit] 2011-11-02 12:01:38,261 [myid:] - INFO [main:FileTxnSnapLog@255] - Snapshotting: b [junit] 2011-11-02 12:01:38,262 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 12:01:38,262 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:41451 [junit] 2011-11-02 12:01:38,263 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@820] - Processing stat command from /127.0.0.1:41451 [junit] 2011-11-02 12:01:38,263 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@655] - Stat command output [junit] 2011-11-02 12:01:38,263 [myid:] - INFO [Thread-5:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:41451 (no session established for client) [junit] 2011-11-02 12:01:38,263 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 12:01:38,264 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 12:01:38,264 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 12:01:38,265 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 12:01:38,265 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 12:01:38,265 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2011-11-02 12:01:38,265 [myid:] - INFO [main:ClientBase@465] - tearDown starting [junit] 2011-11-02 12:01:38,348 [myid:] - INFO [main:ZooKeeper@679] - Session: 0x1336427eca8 closed [junit]
[jira] [Updated] (BOOKKEEPER-82) support journal rolling
[ https://issues.apache.org/jira/browse/BOOKKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sijie Guo updated BOOKKEEPER-82: Fix Version/s: 4.0.0 support journal rolling --- Key: BOOKKEEPER-82 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-82 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Affects Versions: 3.4.0 Reporter: Sijie Guo Assignee: Sijie Guo Fix For: 4.0.0 Attachments: bookkeeper-82.patch now bookkeeper is writing a single journal file, so the journal file has no chance to be garbage collected and the disk space keeps growing. -- 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] (BOOKKEEPER-50) NullPointException at LedgerDescriptor#cmpMasterKey
[ https://issues.apache.org/jira/browse/BOOKKEEPER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sijie Guo updated BOOKKEEPER-50: Fix Version/s: 4.0.0 NullPointException at LedgerDescriptor#cmpMasterKey --- Key: BOOKKEEPER-50 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-50 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-server Affects Versions: 3.4.0 Reporter: xulei Fix For: 4.0.0 Attachments: BookieReadAfterBookieRestartTest.java, bookkeeper-50.patch the LedgerDescriptor will be created when it is missed in LedgerCache. NullPointException will be thrown out in the following case: 1. The ledger descriptor is created and cached to LedgerCache because of a readEntry operation in bookie. The ledger descriptor was created without setting master key (we don't know master key in a read request) 2. An addEntry is sent after 1 . since the ledger descriptor has been cached, so addEntry will use it to compare master key. then NullPointException is thrown out. -- 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] [Reopened] (ZOOKEEPER-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch reopened ZOOKEEPER-1246: I'm sorry to reopen this issue after the fact, but if everybody would review every patch, we would loose a lot of time. minor issues: - The patch adds trailing whitespace. - The new test file does not use unix newlines. - Indentation in line 507 misses a space. - The test file contains auto generated TODO comments that actually aren't TODOs. - The added if statements are not consistent. One of them uses braces, the others don't. - The test file introduces a new Warning about unused imports. - The patch does change the method signature but not the method javadoc comment. - The new added test case does not indicate what it actually tests. It could either - have a more explanatory name - describe the tested Bug in a comment - or just have at least the jira issue mentioned in a comment - The test comes with an implementation of SessionTracker to set up a full blown ZooKeeperServer. That's not necessary. One can just use the LearnerSessionHandler. major issues: - The added Test isn't a Unit Test. It instantiates several other unrelated classes and even touches network and file system. - The patch increases the complexity of the code and couples it even more to the Jute model of deserializing a pre-instantiated object. - The patch adds another parameter to the pRequest2Txn method and thus also makes it harder to read. - The patch does not address the issue that Exception is catched in line 585 instead of IOException. There would have been a trivial fix instead. Just add the setHdr statement conditionally before the switch statement inside the try: {code:java} if(Request.isQuorum()) { request.setHdr( ... ) } {code} Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Camille Fournier Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-1246: --- Attachment: ZOOKEEPER-1246.patch This patch - reverts the changes made to PrepRequestProcessor - fixes the issue instead by setting the Request hdr before entering the switch statement - removes the MySessionTracker implementation from the Test - changes the last catch block to catch IOException instead of Exception bonus: - The pRequest2Txn method lost the zxid parameter without being sad about it. - There's only one place remaining that calls ZooKeeperServer.getNextZxid() Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Camille Fournier Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-1246: --- Attachment: ZOOKEEPER-1246.patch - Forgot to mention: The original patch does not obey the 80 characters limit for newly introduced lines. I've renamed the test method now and added a comment to the test to relate it to this issue. Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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-1250) trigger jenkins dummy issue
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Koch updated ZOOKEEPER-1250: --- Attachment: ZOOKEEPER-1250_deserialization_returns_dataNode.patch trigger jenkins dummy issue --- Key: ZOOKEEPER-1250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Trivial Attachments: ZOOKEEPER-1250.145d386_triggerwatches_out.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.c121ec_jute_out_datanode.patch, ZOOKEEPER-1250.d23d30_copyStat_getStat.patch, ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch, ZOOKEEPER-1250_deserialization_returns_dataNode.patch, ZOOKEEPER-1250_watches_out_datatree.patch Sorry, I don't have my own servers for testing, so I need to upload patches here to run the ZK test suite. -- 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-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142125#comment-13142125 ] Hadoop QA commented on ZOOKEEPER-1246: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501955/ZOOKEEPER-1246.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 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/762//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/762//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/762//console This message is automatically generated. Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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
Re: Comment from Martin Fowler
the tests aren't green dude! that is exactly what i proposed waiting for. ben On Wed, Nov 2, 2011 at 2:57 AM, Thomas Koch tho...@koch.ro wrote: Martin Fowler wrote a comment yesterday on our recent discussion about refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html Regards, Thomas Koch, http://www.koch.ro
[jira] [Commented] (ZOOKEEPER-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142136#comment-13142136 ] Hadoop QA commented on ZOOKEEPER-1246: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501957/ZOOKEEPER-1246.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 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/764//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/764//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/764//console This message is automatically generated. Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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-1250) trigger jenkins dummy issue
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142153#comment-13142153 ] Hadoop QA commented on ZOOKEEPER-1250: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501958/ZOOKEEPER-1250_deserialization_returns_dataNode.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 79 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 appears to introduce 2 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/763//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/763//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/763//console This message is automatically generated. trigger jenkins dummy issue --- Key: ZOOKEEPER-1250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Trivial Attachments: ZOOKEEPER-1250.145d386_triggerwatches_out.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.c121ec_jute_out_datanode.patch, ZOOKEEPER-1250.d23d30_copyStat_getStat.patch, ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch, ZOOKEEPER-1250_deserialization_returns_dataNode.patch, ZOOKEEPER-1250_watches_out_datatree.patch Sorry, I don't have my own servers for testing, so I need to upload patches here to run the ZK test suite. -- 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
Success: ZOOKEEPER-1246 PreCommit Build #764
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/764/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 145360 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501957/ZOOKEEPER-1246.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [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/764//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/764//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/764//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] 258UOoNa5z logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 22 minutes 28 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1246 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
Review Request: ZOOKEEPER-1246 Dead code in PrepRequestProcessor catch Exception block
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2671/ --- Review request for zookeeper. Summary --- This is _not_ a diff againt current trunk but against the trunk _before_ the first version of the ZK-1246 patch got committed. This addresses bug ZOOKEEPER-1246. https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Diffs - CHANGES.txt 8ed2bc2 src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 1a80d74 src/java/test/org/apache/zookeeper/server/PrepRequestProcessorTest.java PRE-CREATION Diff: https://reviews.apache.org/r/2671/diff Testing --- Thanks, Thomas
Re: Comment from Martin Fowler
He also mentions the need for good judgement, which is a trait you appear to be sorely lacking. From my phone On Nov 2, 2011 5:58 AM, Thomas Koch tho...@koch.ro wrote: Martin Fowler wrote a comment yesterday on our recent discussion about refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html Regards, Thomas Koch, http://www.koch.ro
[jira] [Commented] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142182#comment-13142182 ] Benjamin Reed commented on ZOOKEEPER-1264: -- just a quick update. i'm able to reproduce the problem quickly and deterministicly with a unit test. it has to do with the snapshot transfer. it is not getting recorded with the correct zxid. i'll have the fix shortly. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1250 PreCommit Build #765
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/765/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 137837 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501971/ZOOKEEPER-1250_deserialization_returns_dataNode.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 79 new or modified tests. [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 appears to introduce 2 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/765//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/765//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/765//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] 1LbDC11W93 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:1576: exec returned: 1 Total time: 22 minutes 17 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1250 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1250) trigger jenkins dummy issue
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142203#comment-13142203 ] Hadoop QA commented on ZOOKEEPER-1250: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501971/ZOOKEEPER-1250_deserialization_returns_dataNode.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 79 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 appears to introduce 2 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/765//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/765//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/765//console This message is automatically generated. trigger jenkins dummy issue --- Key: ZOOKEEPER-1250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1250 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Trivial Attachments: ZOOKEEPER-1250.145d386_triggerwatches_out.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.a948f6f_jute_out_datanode.patch, ZOOKEEPER-1250.c121ec_jute_out_datanode.patch, ZOOKEEPER-1250.d23d30_copyStat_getStat.patch, ZOOKEEPER-1250_b9e5a17_tree_deserialzation.patch, ZOOKEEPER-1250_deserialization_returns_dataNode.patch, ZOOKEEPER-1250_deserialization_returns_dataNode.patch, ZOOKEEPER-1250_watches_out_datatree.patch Sorry, I don't have my own servers for testing, so I need to upload patches here to run the ZK test suite. -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-1264: - Attachment: ZOOKEEPER-1264unittest.patch here is the unit test. doing a snapshot at UPDATE will make this test pass, but i'm afraid it is masking a deeper problem. the question is, why does it fix the problem? FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142211#comment-13142211 ] Camille Fournier commented on ZOOKEEPER-1264: - Because when the follower writes a new log file without writing a snapshot with the old transactions, on restart the ZK thinks it has the transactions up to the zxid in the log file. The fact that these transactions were never written to a log or snapshot by the follower is not captured. We got a NEWLEADER and took a snapshot, then got a bunch of txns that went directly to our data tree, then got UPTODATE, then some other new transactions that caused the creation of a brand new log file. The intermediate transactions between NEWLEADER and UPTODATE are never written to a persistent store on the follower unless it manages to stay alive long enough to do another snapshot. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1264 PreCommit Build #766
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/766/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 137520 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501973/ZOOKEEPER-1264unittest.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [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 failed 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/766//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/766//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/766//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] vI9m3GYn4M 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:1576: exec returned: 1 Total time: 18 minutes 51 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1264 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. FAILED: org.apache.zookeeper.server.quorum.Zab1_0Test.testNormalFollowerRun Error Message: expected:data[2] but was:data[1] Stack Trace: at org.apache.zookeeper.server.quorum.Zab1_0Test$2.converseWithFollower(Zab1_0Test.java:352) at org.apache.zookeeper.server.quorum.Zab1_0Test.testFollowerConversation(Zab1_0Test.java:212) at org.apache.zookeeper.server.quorum.Zab1_0Test.testNormalFollowerRun(Zab1_0Test.java:230)
[jira] [Commented] (ZOOKEEPER-1269) Multi deserialization issues
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142225#comment-13142225 ] Camille Fournier commented on ZOOKEEPER-1269: - I think it should go into both, since it is a bug with multi. Multi deserialization issues Key: ZOOKEEPER-1269 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1269 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.4.0 Reporter: Camille Fournier Assignee: Camille Fournier Attachments: ZOOKEEPER-1269.patch From the mailing list: FileTxnSnapLog.restore contains a code block handling a NODEEXISTS failure during deserialization. The problem is explained there in a code comment. The code block however is only executed for a CREATE txn, not for a multiTxn containing a CREATE. Even if the mentioned code block would also be executed for multi transactions, it needs adaption for multi transactions. What, if after the first failed transaction in a multi txn during deserialization, there would be subsequent transactions in the same multi that would also have failed? We don't know, since the first failed transaction hides the information about the remaining transactions. -- 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
Re: Comment from Martin Fowler
Perhaps we are being too nice when we should be direct. See how a similar thread was recently handled on hadoop: http://markmail.org/message/qswdx5yuvpsetwis Patrick On Wed, Nov 2, 2011 at 7:01 AM, Camille Fournier cami...@apache.org wrote: He also mentions the need for good judgement, which is a trait you appear to be sorely lacking. From my phone On Nov 2, 2011 5:58 AM, Thomas Koch tho...@koch.ro wrote: Martin Fowler wrote a comment yesterday on our recent discussion about refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html Regards, Thomas Koch, http://www.koch.ro
[jira] [Updated] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-1264: - Attachment: ZOOKEEPER-1264.patch i think i got it. camille can you try it with your test to see if it's fixed there as well? (the tests always passed on my machine.) FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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
Re: Comment from Martin Fowler
I have to say that the entire my code is bigger than your code episode in the Hadoop community should just be considered embarrassing for all concerned. That includes the ones who started it, Thomas K who posted a holier-than-thou (but essentially correct) comment, and Thomas J who posted a silly put-down in reply. Let me also save anybody else the breath and say that I have said things at least as rude as what Thomas J said and at least as naive as what Thomas K. I plan to keep on saying both kinds of things, but in smaller quantities. I think that Thomas Koch has good contributions to make and lots of energy and lots of fascination with Zookeeper. That is great, but so far somewhat less effective than it could be. If we can help him channel that energy a bit more, then it will be much, much better. I also think that Zookeeper has lots of technical debt, partly because we didn't get to start with a codebase designed for testing. Paying off debt is always extremely painful. We have a payment due. On Wed, Nov 2, 2011 at 8:50 AM, Patrick Hunt ph...@apache.org wrote: Perhaps we are being too nice when we should be direct. See how a similar thread was recently handled on hadoop: http://markmail.org/message/qswdx5yuvpsetwis Patrick On Wed, Nov 2, 2011 at 7:01 AM, Camille Fournier cami...@apache.org wrote: He also mentions the need for good judgement, which is a trait you appear to be sorely lacking. From my phone On Nov 2, 2011 5:58 AM, Thomas Koch tho...@koch.ro wrote: Martin Fowler wrote a comment yesterday on our recent discussion about refactoring: http://martinfowler.com/bliki/OpportunisticRefactoring.html Regards, Thomas Koch, http://www.koch.ro
[jira] [Created] (ZOOKEEPER-1276) ZKDatabase should not hold reference to FileTxnSnapLog
ZKDatabase should not hold reference to FileTxnSnapLog -- Key: ZOOKEEPER-1276 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1276 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Minor The ZkDatabase class contains a reference to a FileTxnSnapLog although it doesn't need it. It has four methods that just forward calls to the instance and two methods that could receive an instance of FileTxnSnapLog instead of refering to a member of _this_. -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142274#comment-13142274 ] Camille Fournier commented on ZOOKEEPER-1264: - Seems to work. I want to go ahead and put in the additional changes to FollowerResyncConcurrencyTest along with your patch after I finish reviewing it. Theoretically they aren't needed but given how many times this test has caught issues I think it's worth it to double-test this stuff. Let me know if you disagree. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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] [Created] (ZOOKEEPER-1277) servers stop serving when lower 32bits of zxid roll over
servers stop serving when lower 32bits of zxid roll over Key: ZOOKEEPER-1277 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1277 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.3.3 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Blocker Fix For: 3.3.4 When the lower 32bits of a zxid roll over (zxid is a 64 bit number, however the upper 32 are considered the epoch number) the epoch number (upper 32 bits) are incremented and the lower 32 start at 0 again. This should work fine, however in the current 3.3 branch the followers see this as a NEWLEADER message, which it's not, and effectively stop serving clients. Attached clients seem to eventually time out given that heartbeats (or any operation) are no longer processed. The follower doesn't recover from this. I've tested this out on 3.3 branch and confirmed this problem, however I haven't tried it on 3.4/3.5. It may not happen on the newer branches due to ZOOKEEPER-335, however there is certainly an issue with updating the acceptedEpoch files contained in the datadir. (I'll enter a separate jira for that) -- 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-1277) servers stop serving when lower 32bits of zxid roll over
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1277: Release Note: Workaround: there is a simple workaround for this issue. Force a leader re-election before the lower 32bits reach 0x Most users won't even see this given the number of writes on a typical installation - say you are doing 500 writes/second, you'd see this after ~3 months if the quorum is stable, any changes (such as upgrading the server software) would cause the xid to be reset, thereby staving off this issue for another period. servers stop serving when lower 32bits of zxid roll over Key: ZOOKEEPER-1277 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1277 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.3.3 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Blocker Fix For: 3.3.4 When the lower 32bits of a zxid roll over (zxid is a 64 bit number, however the upper 32 are considered the epoch number) the epoch number (upper 32 bits) are incremented and the lower 32 start at 0 again. This should work fine, however in the current 3.3 branch the followers see this as a NEWLEADER message, which it's not, and effectively stop serving clients. Attached clients seem to eventually time out given that heartbeats (or any operation) are no longer processed. The follower doesn't recover from this. I've tested this out on 3.3 branch and confirmed this problem, however I haven't tried it on 3.4/3.5. It may not happen on the newer branches due to ZOOKEEPER-335, however there is certainly an issue with updating the acceptedEpoch files contained in the datadir. (I'll enter a separate jira for that) -- 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
Success: ZOOKEEPER-1264 PreCommit Build #767
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/767/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 135007 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12501981/ZOOKEEPER-1264.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [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/767//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/767//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/767//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] 7ff3l8kZgB logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 22 minutes 26 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1264 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Created] (ZOOKEEPER-1278) acceptedEpoch not handling zxid rollover in lower 32bits
acceptedEpoch not handling zxid rollover in lower 32bits Key: ZOOKEEPER-1278 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1278 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.4.0, 3.5.0 Reporter: Patrick Hunt Priority: Blocker Fix For: 3.5.0, 3.4.1 When the lower 32bits of a zxid roll over (zxid is a 64 bit number, however the upper 32 are considered the epoch number) the epoch number (upper 32 bits) are incremented and the lower 32 start at 0 again. This should work fine, however, afaict, in the current 3.4/3.5 the acceptedEpoch/currentEpoch files are not being updated for this case. See ZOOKEEPER-335 for changes from 3.3 branch. -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142292#comment-13142292 ] Hadoop QA commented on ZOOKEEPER-1264: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501981/ZOOKEEPER-1264.patch against trunk revision 1196025. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 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/767//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/767//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/767//console This message is automatically generated. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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] [Created] (ZOOKEEPER-1279) Only SessionTracker should hold reference to sessionsWithTimeouts
Only SessionTracker should hold reference to sessionsWithTimeouts - Key: ZOOKEEPER-1279 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1279 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Minor Currently the ZKDataBase, ZooKeeperServer and SessionTrackers hold references to the same map, called sessionsWithTimeouts everywhere. That's very confusing. It is possible to have the reference only in the SessionTrackers and take it from there if it should ever be needed outside. -- 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] [Created] (ZOOKEEPER-1280) Add current epoch number and timestamp of when it began to 4 letter words (stat, srvr, mntr maybe?)
Add current epoch number and timestamp of when it began to 4 letter words (stat, srvr, mntr maybe?) --- Key: ZOOKEEPER-1280 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1280 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.3.3 Reporter: Daniel Lord It would be nice if there were some stats displayed about the current epoch in the 4 letter words. At the very least it would be nice to expose the current epoch number (I know I could parse it from the Zxid but exposing it directly is more transparent) and the date of when the epoch began. -- 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] [Created] (ZOOKEEPER-1281) Stat and srvr 4 letter commands are useless on the leader when leaderServes = false
Stat and srvr 4 letter commands are useless on the leader when leaderServes = false --- Key: ZOOKEEPER-1281 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1281 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.3.3 Reporter: Daniel Lord When leaderServes = false the leader responds to the stat/srvr letter words with simply his ZooKeeper instance is not currently serving requests. While I agree that is an accurate statement it's not terribly useful for monitoring programs. Additionally, if members of the ensemble are not currently in the quorum it becomes impossible to tell who is out of the quorum and who is the leader of the quorum. I'm not sure if the leader should have a specially formatted response for stat/srvr or if it should simply display less information (no connections for example). -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142328#comment-13142328 ] Benjamin Reed commented on ZOOKEEPER-1264: -- i agree, we should have the extra test. it is nice to have the extra coverage. do you want to generate a merged patch? FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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
Re: Comment from Martin Fowler
On Wed, Nov 2, 2011 at 10:10 AM, Patrick Hunt ph...@apache.org wrote: On Wed, Nov 2, 2011 at 9:34 AM, Ted Dunning ted.dunn...@gmail.com wrote: ... I also think that Zookeeper has lots of technical debt, partly because we didn't get to start with a codebase designed for testing. Paying off debt is always extremely painful. We have a payment due. Ted, no disrespect but put your money where you mouth is, start reviewing patches if you feel strongly. Guilty (mostly) as charged. I have only been able to review a few of the patches. My work schedule is heinous right now. So far I've taken the brunt of doing the reviews from Thomas and the rest of the community is just getting pissed off by his attitude. I have also tried to work on this issue. I have met with Thomas in person and provided private coaching (with limited, but non-zero success). I also have privately mediated some misunderstandings. It doesn't matter what someones contributions might be, if they can't work with the community. http://communityovercode.com/over/ Very true. That is why I have tried to work to help Thomas learn how to work with this community. It isn't all about a snapshot in time; people can develop new skills.
[jira] [Commented] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142373#comment-13142373 ] Camille Fournier commented on ZOOKEEPER-1264: - Yup will do asap (which might be early this evening but I'll try to get it in a few mins). FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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
Re: Comment from Martin Fowler
On Wed, Nov 2, 2011 at 11:15 AM, Ted Dunning ted.dunn...@gmail.com wrote: On Wed, Nov 2, 2011 at 10:10 AM, Patrick Hunt ph...@apache.org wrote: On Wed, Nov 2, 2011 at 9:34 AM, Ted Dunning ted.dunn...@gmail.com wrote: ... I also think that Zookeeper has lots of technical debt, partly because we didn't get to start with a codebase designed for testing. Â Paying off debt is always extremely painful. Â We have a payment due. Ted, no disrespect but put your money where you mouth is, start reviewing patches if you feel strongly. Guilty (mostly) as charged. I have only been able to review a few of the patches. Â My work schedule is heinous right now. Totally understand (I'm in the same boat wrt being overloaded). Hope you took it in the context I meant it. We can't do hugs through email -- raincheck for next time we meet f2f. ;-) So far I've taken the brunt of doing the reviews from Thomas and the rest of the community is just getting pissed off by his attitude. I have also tried to work on this issue. Â I have met with Thomas in person and provided private coaching (with limited, but non-zero success). Â I also have privately mediated some misunderstandings. It doesn't matter what someones contributions might be, if they can't work with the community. http://communityovercode.com/over/ Very true. Â That is why I have tried to work to help Thomas learn how to work with this community. Â It isn't all about a snapshot in time; people can develop new skills. That's the thing, so far everyone has been trying (incl Thomas) but we are still seeing friction. Perhaps it's just the limited time available, pressure to get 3.4.0 out, and non-alignment btw Thomas's interests and our current goals? Patrick
Re: Comment from Martin Fowler
On Wed, Nov 2, 2011 at 11:23 AM, Patrick Hunt ph...@apache.org wrote: Very true. That is why I have tried to work to help Thomas learn how to work with this community. It isn't all about a snapshot in time; people can develop new skills. That's the thing, so far everyone has been trying (incl Thomas) but we are still seeing friction. Perhaps it's just the limited time available, pressure to get 3.4.0 out, and non-alignment btw Thomas's interests and our current goals? Indeed. And language issues. And cultural history. And software cultural differences. Who knows what else. Thomas is much more reasonable and easy to deal with in person. That surprised me.
[jira] [Commented] (ZOOKEEPER-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142392#comment-13142392 ] Camille Fournier commented on ZOOKEEPER-1246: - Thomas, a bit of feedback. This is unnecessarily aggressive and annoying, and coming after I smacked you down for not writing tests for your own bugfixes it makes you look incredibly petty and insecure. It is perfectly fair of you to point out that I added an eclipse warning (guilty as charged, but if you really care about these you need to make the build fail when additional warnings are added). And yes, the formatting is not perfect. But as to most of the rest of your points, you can frankly go to hell if you think I'm going to tolerate being condescended to in this manner. You had the opportunity to fix this bug yourself when you reported it. Instead, you pranced off to work on your own thing and left it to me to debug and provide a fix. Now that the fix is done and somehow not to your liking, the best you could hope for here is to request a fix for the warning and formatting errors, and otherwise submit a new patch as a refactor. I'm closing this back up, and you are welcome to open a new issue with formatting fixes/refactors on it if you so choose. But it is certainly not a critical bug any longer. Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Thomas Koch Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Camille Fournier updated ZOOKEEPER-1264: Attachment: ZOOKEEPER-1264-merge.patch FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264-merge.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1246) Dead code in PrepRequestProcessor catch Exception block
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142424#comment-13142424 ] Patrick Hunt commented on ZOOKEEPER-1246: - Once something is committed we generally open a new jira to address further issues or insights people might have. Also, I pointed out on the list, if we want to catch such issues (eclipse warnings say) we need to include tests in the QABOT process - Thomas see my mail to the list on that. If you care about such things we need to enforce it through there as not everyone uses eclipse (same for findbugs, rat etc... that's already included by the bot.). Dead code in PrepRequestProcessor catch Exception block --- Key: ZOOKEEPER-1246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1246 Project: ZooKeeper Issue Type: Sub-task Reporter: Thomas Koch Assignee: Camille Fournier Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246.patch, ZOOKEEPER-1246_trunk.patch, ZOOKEEPER-1246_trunk.patch This is a regression introduced by ZOOKEEPER-965 (multi transactions). The catch(Exception e) block in PrepRequestProcessor.pRequest contains an if block with condition request.getHdr() != null. This condition will always evaluate to false since the changes in ZOOKEEPER-965. This is caused by a change in sequence: Before ZK-965, the txnHeader was set _before_ the deserialization of the request. Afterwards the deserialization happens before request.setHdr is set. So the following RequestProcessors won't see the request as a failed one but as a Read request, since it doesn't have a hdr set. Notes: - it is very bad practice to catch Exception. The block should rather catch IOException - The check whether the TxnHeader is set in the request is used at several places to see whether the request is a read or write request. It isn't obvious for a newby, what it means whether a request has a hdr set or not. - at the beginning of pRequest the hdr and txn of request are set to null. However there is no chance that these fields could ever not be null at this point. The code however suggests that this could be the case. There should rather be an assertion that confirms that these fields are indeed null. The practice of doing things just in case, even if there is no chance that this case could happen, is a very stinky code smell and means that the code isn't understandable or trustworthy. - The multi transaction switch case block in pRequest is very hard to read, because it missuses the request.{hdr|txn} fields as local variables. -- 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
Success: ZOOKEEPER-1264 PreCommit Build #768
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/768/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 139526 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12502007/ZOOKEEPER-1264-merge.patch [exec] against trunk revision 1196025. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 6 new or modified tests. [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/768//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/768//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/768//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] 3H513NW964 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 22 minutes 34 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1264 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Updated] (ZOOKEEPER-1271) testEarlyLeaderAbandonment failing on solaris - clients not retrying connection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-1271: - Attachment: ZOOKEEPER-1271-3.3.patch Patch for 3.3 branch. The code base in 3.3 makes it almost impossible to write a unit test for this. We can just commit the patch for 3.3 branch? Lesser chances of fix getting removed in 3.3. We can just run the patch on solaris machine and see if it works. Sounds good? testEarlyLeaderAbandonment failing on solaris - clients not retrying connection --- Key: ZOOKEEPER-1271 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1271 Project: ZooKeeper Issue Type: Bug Components: java client Affects Versions: 3.3.4, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1271-3.3.patch, ZOOKEEPER-1271-3.4.patch, ZOOKEEPER-1271-trunk.patch, ZOOKEEPER-1271.patch, ZOOKEEPER-1271.patch, solarisClientFailure.txt.gz See: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_solaris/1/testReport/junit/org.apache.zookeeper.server.quorum/QuorumPeerMainTest/testEarlyLeaderAbandonment/ Notice that the clients attempt to connect before the servers have bound, then 30 seconds later, after seemingly no further client activity we see: 2011-10-28 21:40:56,828 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@1057] - Client session timed out, have not heard from server in 30032ms for sessionid 0x0, closing socket connection and attempting reconnect I believe this is different from ZOOKEEPER-1270 because in the 1270 case it seems like the clients are attempting to connect but the servers are not accepting (notice the stat commands are being dropped due to no server running) -- 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-1271 PreCommit Build #769
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1271 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/769/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 64 lines...] [exec] Applying patch. [exec] == [exec] == [exec] [exec] [exec] patching file src/java/main/org/apache/zookeeper/ClientCnxn.java [exec] Hunk #1 FAILED at 1075. [exec] 1 out of 1 hunk FAILED -- saving rejects to file src/java/main/org/apache/zookeeper/ClientCnxn.java.rej [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12502033/ZOOKEEPER-1271-3.3.patch [exec] against trunk revision 1196025. [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 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/769//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] UjlWn5Rn82 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:1576: exec returned: 1 Total time: 38 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1271 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1271) testEarlyLeaderAbandonment failing on solaris - clients not retrying connection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142523#comment-13142523 ] Hadoop QA commented on ZOOKEEPER-1271: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12502033/ZOOKEEPER-1271-3.3.patch against trunk revision 1196025. +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 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/769//console This message is automatically generated. testEarlyLeaderAbandonment failing on solaris - clients not retrying connection --- Key: ZOOKEEPER-1271 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1271 Project: ZooKeeper Issue Type: Bug Components: java client Affects Versions: 3.3.4, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1271-3.3.patch, ZOOKEEPER-1271-3.4.patch, ZOOKEEPER-1271-trunk.patch, ZOOKEEPER-1271.patch, ZOOKEEPER-1271.patch, solarisClientFailure.txt.gz See: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_solaris/1/testReport/junit/org.apache.zookeeper.server.quorum/QuorumPeerMainTest/testEarlyLeaderAbandonment/ Notice that the clients attempt to connect before the servers have bound, then 30 seconds later, after seemingly no further client activity we see: 2011-10-28 21:40:56,828 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@1057] - Client session timed out, have not heard from server in 30032ms for sessionid 0x0, closing socket connection and attempting reconnect I believe this is different from ZOOKEEPER-1270 because in the 1270 case it seems like the clients are attempting to connect but the servers are not accepting (notice the stat commands are being dropped due to no server running) -- 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-1271) testEarlyLeaderAbandonment failing on solaris - clients not retrying connection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142575#comment-13142575 ] Patrick Hunt commented on ZOOKEEPER-1271: - I don't see any way to add a test in 3.3 either w/o significant structural changes (such as the refactorings that went into 3.4, allowing the mock testing used there). Given we can reproduce this on apache jenkins solaris systems, it seems that we already have test coverage for this. no? testEarlyLeaderAbandonment failing on solaris - clients not retrying connection --- Key: ZOOKEEPER-1271 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1271 Project: ZooKeeper Issue Type: Bug Components: java client Affects Versions: 3.3.4, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1271-3.3.patch, ZOOKEEPER-1271-3.4.patch, ZOOKEEPER-1271-trunk.patch, ZOOKEEPER-1271.patch, ZOOKEEPER-1271.patch, solarisClientFailure.txt.gz See: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_solaris/1/testReport/junit/org.apache.zookeeper.server.quorum/QuorumPeerMainTest/testEarlyLeaderAbandonment/ Notice that the clients attempt to connect before the servers have bound, then 30 seconds later, after seemingly no further client activity we see: 2011-10-28 21:40:56,828 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@1057] - Client session timed out, have not heard from server in 30032ms for sessionid 0x0, closing socket connection and attempting reconnect I believe this is different from ZOOKEEPER-1270 because in the 1270 case it seems like the clients are attempting to connect but the servers are not accepting (notice the stat commands are being dropped due to no server running) -- 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-1271) testEarlyLeaderAbandonment failing on solaris - clients not retrying connection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142625#comment-13142625 ] Hudson commented on ZOOKEEPER-1271: --- Integrated in ZooKeeper-trunk #1353 (See [https://builds.apache.org/job/ZooKeeper-trunk/1353/]) ZOOKEEPER-1271. testEarlyLeaderAbandonment failing on solaris - clients not retrying connection (mahadev via phunt) phunt : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1196819 Files : * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/ivy.xml * /zookeeper/trunk/src/java/main/org/apache/zookeeper/ClientCnxnSocketNIO.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/ClientReconnectTest.java testEarlyLeaderAbandonment failing on solaris - clients not retrying connection --- Key: ZOOKEEPER-1271 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1271 Project: ZooKeeper Issue Type: Bug Components: java client Affects Versions: 3.3.4, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1271-3.3.patch, ZOOKEEPER-1271-3.4.patch, ZOOKEEPER-1271-trunk.patch, ZOOKEEPER-1271.patch, ZOOKEEPER-1271.patch, solarisClientFailure.txt.gz See: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_solaris/1/testReport/junit/org.apache.zookeeper.server.quorum/QuorumPeerMainTest/testEarlyLeaderAbandonment/ Notice that the clients attempt to connect before the servers have bound, then 30 seconds later, after seemingly no further client activity we see: 2011-10-28 21:40:56,828 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@1057] - Client session timed out, have not heard from server in 30032ms for sessionid 0x0, closing socket connection and attempting reconnect I believe this is different from ZOOKEEPER-1270 because in the 1270 case it seems like the clients are attempting to connect but the servers are not accepting (notice the stat commands are being dropped due to no server running) -- 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_branch34 - Build # 49 - Failure
See https://builds.apache.org/job/ZooKeeper_branch34/49/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 139389 lines...] [junit] 2011-11-02 22:26:48,353 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 22:26:48,354 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 22:26:48,354 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 22:26:48,354 [myid:] - INFO [main:ClientBase@435] - STOPPING server [junit] 2011-11-02 22:26:48,355 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@240] - NIOServerCnxn factory exited run method [junit] 2011-11-02 22:26:48,355 [myid:] - INFO [main:ZooKeeperServer@420] - shutting down [junit] 2011-11-02 22:26:48,355 [myid:] - INFO [main:SessionTrackerImpl@206] - Shutting down [junit] 2011-11-02 22:26:48,356 [myid:] - INFO [main:PrepRequestProcessor@730] - Shutting down [junit] 2011-11-02 22:26:48,356 [myid:] - INFO [main:SyncRequestProcessor@173] - Shutting down [junit] 2011-11-02 22:26:48,356 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@135] - PrepRequestProcessor exited loop! [junit] 2011-11-02 22:26:48,357 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2011-11-02 22:26:48,358 [myid:] - INFO [main:FinalRequestProcessor@423] - shutdown of request processor complete [junit] 2011-11-02 22:26:48,358 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 22:26:48,359 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2011-11-02 22:26:48,360 [myid:] - INFO [main:ClientBase@428] - STARTING server [junit] 2011-11-02 22:26:48,361 [myid:] - INFO [main:ZooKeeperServer@168] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/branch-3.4/build/test/tmp/test398720548457866748.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/branch-3.4/build/test/tmp/test398720548457866748.junit.dir/version-2 [junit] 2011-11-02 22:26:48,362 [myid:] - INFO [main:NIOServerCnxnFactory@110] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-02 22:26:48,363 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/branch-3.4/build/test/tmp/test398720548457866748.junit.dir/version-2/snapshot.b [junit] 2011-11-02 22:26:48,365 [myid:] - INFO [main:FileTxnSnapLog@255] - Snapshotting: b [junit] 2011-11-02 22:26:48,367 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 22:26:48,368 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:57478 [junit] 2011-11-02 22:26:48,368 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@820] - Processing stat command from /127.0.0.1:57478 [junit] 2011-11-02 22:26:48,369 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@655] - Stat command output [junit] 2011-11-02 22:26:48,369 [myid:] - INFO [Thread-5:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:57478 (no session established for client) [junit] 2011-11-02 22:26:48,369 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 22:26:48,371 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 22:26:48,371 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 22:26:48,372 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 22:26:48,372 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 22:26:48,372 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2011-11-02 22:26:48,373 [myid:] - INFO [main:ClientBase@465] - tearDown starting [junit] 2011-11-02 22:26:48,436 [myid:] - INFO [main:ZooKeeper@679] - Session: 0x133666448e7 closed [junit] 2011-11-02 22:26:48,436 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@511] - EventThread shut down [junit] 2011-11-02 22:26:48,436 [myid:] - INFO [main:ClientBase@435] - STOPPING server [junit] 2011-11-02 22:26:48,437 [myid:] - INFO
ZooKeeper_branch33_solaris - Build # 1 - Failure
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/1/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 88807 lines...] [junit] 2011-11-02 22:41:13,844 - INFO [main:FinalRequestProcessor@378] - shutdown of request processor complete [junit] expect:InMemoryDataTree [junit] 2011-11-02 22:41:13,844 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 22:41:13,846 - INFO [main:ClientBase@415] - STARTING server [junit] expect:StandaloneServer_port [junit] 2011-11-02 22:41:13,846 - 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/test9071469281840823638.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test9071469281840823638.junit.dir/version-2 [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 22:41:13,847 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] ensureOnly:[] [junit] 2011-11-02 22:41:13,848 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test9071469281840823638.junit.dir/version-2/snapshot.0 [junit] 2011-11-02 22:41:13,850 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] 2011-11-02 22:41:13,852 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 22:41:13,852 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:33527 [junit] 2011-11-02 22:41:13,853 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:33527 [junit] 2011-11-02 22:41:13,853 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2011-11-02 22:41:13,854 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:33527 (no session established for client) [junit] 2011-11-02 22:41:13,855 - INFO [main:ClientBase@422] - STOPPING server [junit] 2011-11-02 22:41:13,856 - INFO [ProcessThread:-1:PrepRequestProcessor@120] - PrepRequestProcessor exited loop! [junit] 2011-11-02 22:41:13,856 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2011-11-02 22:41:13,856 - INFO [main:FinalRequestProcessor@378] - shutdown of request processor complete [junit] 2011-11-02 22:41:13,857 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 22:41:13,859 - INFO [main:ClientBase@415] - STARTING server [junit] 2011-11-02 22:41:13,860 - 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/test9071469281840823638.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test9071469281840823638.junit.dir/version-2 [junit] 2011-11-02 22:41:13,861 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 22:41:13,862 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test9071469281840823638.junit.dir/version-2/snapshot.b [junit] expect:InMemoryDataTree [junit] 2011-11-02 22:41:13,865 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 22:41:13,867 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] expect:StandaloneServer_port [junit] 2011-11-02 22:41:13,867 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:33529 [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] ensureOnly:[] [junit] 2011-11-02 22:41:13,868 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:33529 [junit] 2011-11-02 22:41:13,869 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] -
[jira] [Commented] (ZOOKEEPER-1282) Learner.java not following Zab 1.0 protocol - setCurrentEpoch should be done upon receipt of NEWLEADER (before acking it) and not upon receipt of UPTODATE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142638#comment-13142638 ] Benjamin Reed commented on ZOOKEEPER-1282: -- i can easily put a test and fix for this in once ZOOKEEPER-1264 goes in. (we need to move the self.setCurrentEpoch up to after the NEWLEADER. the check is easy to add in the unit test.) Learner.java not following Zab 1.0 protocol - setCurrentEpoch should be done upon receipt of NEWLEADER (before acking it) and not upon receipt of UPTODATE -- Key: ZOOKEEPER-1282 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1282 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.4.0 Reporter: Alexander Shraer according to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0 phase 2 part 2, Once it receives NEWLEADER(e) it atomically applies the new state and sets f.currentEpoch =e. In Learner.java self.setCurrentEpoch(newEpoch) is done after receiving UPTODATE and not before acking the NEWLEADER message as should be. case Leader.UPTODATE: if (!snapshotTaken) { zk.takeSnapshot(); } self.cnxnFactory.setZooKeeperServer(zk); break outerLoop; case Leader.NEWLEADER: // it will be NEWLEADER in v1.0 zk.takeSnapshot(); snapshotTaken = true; writePacket(new QuorumPacket(Leader.ACK, newLeaderZxid, null, null), true); break; } } } long newEpoch = ZxidUtils.getEpochFromZxid(newLeaderZxid); self.setCurrentEpoch(newEpoch); -- 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-1270) testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1270: Fix Version/s: (was: 3.4.1) 3.4.0 Looks like this is still hanging around, see time 2011-11-02 22:11:27,124 https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34/49/testReport/junit/org.apache.zookeeper.server.quorum/QuorumPeerMainTest/testEarlyLeaderAbandonment/ {noformat} 2011-11-02 22:11:27,113 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41413:LearnerHandler@264] - Follower sid: 1 : info : org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer@166340c 2011-11-02 22:11:27,113 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41414:LearnerHandler@264] - Follower sid: 0 : info : org.apache.zookeeper.server.quorum.QuorumPeer$QuorumServer@101ac93 2011-11-02 22:11:27,123 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41413:LearnerHandler@319] - Synchronizing with Follower sid: 1 maxCommittedLog =10003 minCommittedLog = 10001 peerLastZxid = 10003 2011-11-02 22:11:27,123 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41414:LearnerHandler@319] - Synchronizing with Follower sid: 0 maxCommittedLog =10003 minCommittedLog = 10001 peerLastZxid = 10003 2011-11-02 22:11:27,123 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41413:LearnerHandler@407] - Sending snapshot last zxid of peer is 0x10003 zxid of leader is 0x0sent zxid of db as 0x10003 2011-11-02 22:11:27,124 [myid:2] - INFO [LearnerHandler-/127.0.0.1:41414:LearnerHandler@407] - Sending snapshot last zxid of peer is 0x10003 zxid of leader is 0x0sent zxid of db as 0x10003 2011-11-02 22:11:27,123 [myid:1] - INFO [QuorumPeer[myid=1]/0:0:0:0:0:0:0:0:11230:Learner@323] - Getting a snapshot from leader 2011-11-02 22:11:27,124 [myid:0] - INFO [QuorumPeer[myid=0]/0:0:0:0:0:0:0:0:11227:Learner@323] - Getting a snapshot from leader 2011-11-02 22:11:27,125 [myid:1] - INFO [QuorumPeer[myid=1]/0:0:0:0:0:0:0:0:11230:FileTxnSnapLog@255] - Snapshotting: 10003 2011-11-02 22:11:27,125 [myid:0] - INFO [QuorumPeer[myid=0]/0:0:0:0:0:0:0:0:11227:FileTxnSnapLog@255] - Snapshotting: 10003 2011-11-02 22:11:27,373 [myid:] - INFO [main-SendThread(localhost:11233):ClientCnxn$SendThread@933] - Opening socket connection to server localhost/127.0.0.1:11233 2011-11-02 22:11:27,373 [myid:] - INFO [main-SendThread(localhost:11233):ClientCnxn$SendThread@846] - Socket connection established to localhost/127.0.0.1:11233, initiating session 2011-11-02 22:11:27,373 [myid:2] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11233:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:37239 2011-11-02 22:11:27,374 [myid:2] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11233:NIOServerCnxn@354] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2011-11-02 22:11:27,374 [myid:2] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11233:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:37239 (no session established for client) 2011-11-02 22:11:27,374 [myid:] - INFO [main-SendThread(localhost:11233):ClientCnxn$SendThread@1059] - Unable to read additional data from server sessionid 0x233665616f2, likely server has closed socket, closing socket connection and attempting reconnect 2011-11-02 22:11:27,714 [myid:] - INFO [main-SendThread(localhost:11230):ClientCnxn$SendThread@933] - Opening socket connection to server localhost/127.0.0.1:11230 2011-11-02 22:11:27,714 [myid:] - INFO [main-SendThread(localhost:11230):ClientCnxn$SendThread@846] - Socket connection established to localhost/127.0.0.1:11230, initiating session 2011-11-02 22:11:27,714 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11230:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:33215 2011-11-02 22:11:27,715 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11230:NIOServerCnxn@354] - Exception causing close of session 0x0 due to java.io.IOException: ZooKeeperServer not running 2011-11-02 22:11:27,715 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11230:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:33215 (no session established for client) 2011-11-02 22:11:27,715 [myid:] - INFO [main-SendThread(localhost:11230):ClientCnxn$SendThread@1059] - Unable to read additional data from server sessionid 0x133665616f5, likely server has closed socket, closing socket connection and attempting reconnect 2011-11-02 22:11:27,843 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@933] - Opening socket connection to server localhost/127.0.0.1:11227 2011-11-02 22:11:27,843 [myid:] - INFO [main-SendThread(localhost:11227):ClientCnxn$SendThread@846] - Socket connection established to localhost/127.0.0.1:11227, initiating session {noformat}
ZooKeeper_branch34_solaris - Build # 6 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch34_solaris/6/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 100297 lines...] [junit] 2011-11-02 23:00:49,478 [myid:] - INFO [Thread-4:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:43910 (no session established for client) [junit] 2011-11-02 23:00:49,478 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 23:00:49,479 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 23:00:49,480 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 23:00:49,480 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 23:00:49,481 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 23:00:49,481 [myid:] - INFO [main:ClientBase@435] - STOPPING server [junit] 2011-11-02 23:00:49,482 [myid:] - INFO [main:ZooKeeperServer@420] - shutting down [junit] 2011-11-02 23:00:49,483 [myid:] - INFO [main:SessionTrackerImpl@206] - Shutting down [junit] 2011-11-02 23:00:49,484 [myid:] - INFO [main:PrepRequestProcessor@730] - Shutting down [junit] 2011-11-02 23:00:49,484 [myid:] - INFO [main:SyncRequestProcessor@173] - Shutting down [junit] 2011-11-02 23:00:49,484 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@135] - PrepRequestProcessor exited loop! [junit] 2011-11-02 23:00:49,485 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2011-11-02 23:00:49,486 [myid:] - INFO [main:FinalRequestProcessor@423] - shutdown of request processor complete [junit] 2011-11-02 23:00:49,487 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 23:00:49,487 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2011-11-02 23:00:49,489 [myid:] - INFO [main:ClientBase@428] - STARTING server [junit] 2011-11-02 23:00:49,489 [myid:] - INFO [main:ZooKeeperServer@168] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test3123027825111483576.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test3123027825111483576.junit.dir/version-2 [junit] 2011-11-02 23:00:49,490 [myid:] - INFO [main:NIOServerCnxnFactory@110] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-02 23:00:49,491 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test3123027825111483576.junit.dir/version-2/snapshot.b [junit] 2011-11-02 23:00:49,494 [myid:] - INFO [main:FileTxnSnapLog@255] - Snapshotting: b [junit] 2011-11-02 23:00:49,496 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 23:00:49,497 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:43912 [junit] 2011-11-02 23:00:49,497 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@820] - Processing stat command from /127.0.0.1:43912 [junit] 2011-11-02 23:00:49,498 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@655] - Stat command output [junit] 2011-11-02 23:00:49,498 [myid:] - INFO [Thread-5:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:43912 (no session established for client) [junit] 2011-11-02 23:00:49,499 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 23:00:49,501 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 23:00:49,501 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 23:00:49,502 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 23:00:49,502 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 23:00:49,503 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2011-11-02 23:00:49,503 [myid:] - INFO [main:ClientBase@465] - tearDown starting [junit] 2011-11-02 23:00:49,569 [myid:] - INFO [main:ZooKeeper@679] - Session: 0x13366836e0b closed
ZooKeeper-trunk-solaris - Build # 36 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/36/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 99979 lines...] [junit] 2011-11-02 23:01:22,815 [myid:] - INFO [Thread-4:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:43993 (no session established for client) [junit] 2011-11-02 23:01:22,815 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 23:01:22,816 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 23:01:22,816 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 23:01:22,816 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 23:01:22,816 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 23:01:22,816 [myid:] - INFO [main:ClientBase@435] - STOPPING server [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [main:ZooKeeperServer@391] - shutting down [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [main:SessionTrackerImpl@206] - Shutting down [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [main:PrepRequestProcessor@694] - Shutting down [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [main:SyncRequestProcessor@173] - Shutting down [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@134] - PrepRequestProcessor exited loop! [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@155] - SyncRequestProcessor exited! [junit] 2011-11-02 23:01:22,817 [myid:] - INFO [main:FinalRequestProcessor@419] - shutdown of request processor complete [junit] 2011-11-02 23:01:22,818 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 23:01:22,818 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2011-11-02 23:01:22,819 [myid:] - INFO [main:ClientBase@428] - STARTING server [junit] 2011-11-02 23:01:22,819 [myid:] - INFO [main:ZooKeeperServer@143] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9087558123199437173.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9087558123199437173.junit.dir/version-2 [junit] 2011-11-02 23:01:22,820 [myid:] - INFO [main:NIOServerCnxnFactory@110] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-02 23:01:22,820 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9087558123199437173.junit.dir/version-2/snapshot.b [junit] 2011-11-02 23:01:22,822 [myid:] - INFO [main:FileTxnSnapLog@255] - Snapshotting: b [junit] 2011-11-02 23:01:22,823 [myid:] - INFO [main:ClientBase@227] - connecting to 127.0.0.1 11221 [junit] 2011-11-02 23:01:22,823 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@213] - Accepted socket connection from /127.0.0.1:43995 [junit] 2011-11-02 23:01:22,824 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@820] - Processing stat command from /127.0.0.1:43995 [junit] 2011-11-02 23:01:22,824 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@655] - Stat command output [junit] 2011-11-02 23:01:22,824 [myid:] - INFO [Thread-5:NIOServerCnxn@1000] - Closed socket connection for client /127.0.0.1:43995 (no session established for client) [junit] 2011-11-02 23:01:22,824 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2011-11-02 23:01:22,825 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2011-11-02 23:01:22,825 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2011-11-02 23:01:22,825 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2011-11-02 23:01:22,826 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2011-11-02 23:01:22,826 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2011-11-02 23:01:22,826 [myid:] - INFO [main:ClientBase@465] - tearDown starting [junit] 2011-11-02 23:01:22,908 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@511] - EventThread shut down
FYI ZOOKEEPER-1271 is in, solaris working again!
I've committed Mahadev's fix for ZOOKEEPER-1271 and it seems to have fixed the problem, evidenced by ZK running again on solaris: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_solaris/ Patrick
[jira] [Commented] (ZOOKEEPER-1270) testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142709#comment-13142709 ] Mahadev konar commented on ZOOKEEPER-1270: -- Looks like the zookeeperserver does not start running within the Quorum Peers. There is something really wrong which prevents the Followers/leaders to start running the ZooKeeperServers. I suspect, it has something to do with NEWLeader transaction (could be wrong). Need to look deeper. Another pair of eyes would help! testEarlyLeaderAbandonment failing intermittently, quorum formed, no serving. - Key: ZOOKEEPER-1270 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1270 Project: ZooKeeper Issue Type: Bug Components: server Reporter: Patrick Hunt Priority: Blocker Fix For: 3.4.0, 3.5.0 Attachments: testEarlyLeaderAbandonment.txt.gz, testEarlyLeaderAbandonment2.txt.gz Looks pretty serious - quorum is formed but no clients can attach. Will attach logs momentarily. This test was introduced in the following commit (all three jira commit at once): ZOOKEEPER-335. zookeeper servers should commit the new leader txn to their logs. ZOOKEEPER-1081. modify leader/follower code to correctly deal with new leader ZOOKEEPER-1082. modify leader election to correctly take into account current -- 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-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-1264: - Attachment: ZOOKEEPER-1264.patch this patch merges camille's test in as well. it also adds a couple of extra asserts to cover ZOOKEEPER-1282. finally, it also moves around a couple of lines to fix ZOOKEEPER-1282. (i merged in 1282 because the fix and tests were simple modifications of this patch and we need to get this out asap.) FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264-merge.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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] [Created] (ZOOKEEPER-1283) building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though)
building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though) Key: ZOOKEEPER-1283 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1283 Project: ZooKeeper Issue Type: Bug Components: build Affects Versions: 3.3.3 Reporter: Patrick Hunt Priority: Blocker Fix For: 3.3.4 I tried to compile 3.3.3 or the current 3.3 branch head, in both cases using ant 1.8.2 fails, however 1.7.0 is successful here's the error: {noformat} Testsuite: org.apache.zookeeper.VerGenTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.009 sec Testcase: warning took 0.001 sec FAILED Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() {noformat} -- 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
Success: ZOOKEEPER-1264 PreCommit Build #770
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/770/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 140714 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12502100/ZOOKEEPER-1264.patch [exec] against trunk revision 1196819. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 6 new or modified tests. [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/770//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/770//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/770//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] 3GlhsMjhPF logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 23 minutes 22 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1264 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142852#comment-13142852 ] Hadoop QA commented on ZOOKEEPER-1264: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12502100/ZOOKEEPER-1264.patch against trunk revision 1196819. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 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/770//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/770//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/770//console This message is automatically generated. FollowerResyncConcurrencyTest failing intermittently Key: ZOOKEEPER-1264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1264 Project: ZooKeeper Issue Type: Bug Components: tests Affects Versions: 3.3.3, 3.4.0, 3.5.0 Reporter: Patrick Hunt Assignee: Camille Fournier Priority: Blocker Fix For: 3.3.4, 3.4.0, 3.5.0 Attachments: ZOOKEEPER-1264-merge.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264.patch, ZOOKEEPER-1264_branch33.patch, ZOOKEEPER-1264_branch34.patch, ZOOKEEPER-1264unittest.patch, ZOOKEEPER-1264unittest.patch, followerresyncfailure_log.txt.gz, logs.zip, tmp.zip The FollowerResyncConcurrencyTest test is failing intermittently. saw the following on 3.4: {noformat} junit.framework.AssertionFailedError: Should have same number of ephemerals in both followers expected:11741 but was:14001 at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.verifyState(FollowerResyncConcurrencyTest.java:400) at org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:196) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) {noformat} -- 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-1283) building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1283: Attachment: ZOOKEEPER-1283.patch this patch fixes the problem, I tested using both 1.8.2 and 1.7.1 building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though) Key: ZOOKEEPER-1283 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1283 Project: ZooKeeper Issue Type: Bug Components: build Affects Versions: 3.3.3 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Blocker Fix For: 3.3.4 Attachments: ZOOKEEPER-1283.patch I tried to compile 3.3.3 or the current 3.3 branch head, in both cases using ant 1.8.2 fails, however 1.7.0 is successful here's the error: {noformat} Testsuite: org.apache.zookeeper.VerGenTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.009 sec Testcase: warning took 0.001 sec FAILED Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() {noformat} -- 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-1283) building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13142856#comment-13142856 ] Hadoop QA commented on ZOOKEEPER-1283: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12502102/ZOOKEEPER-1283.patch against trunk revision 1196819. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/771//console This message is automatically generated. building 3.3 branch fails with Ant 1.8.2 (success with 1.7.1 though) Key: ZOOKEEPER-1283 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1283 Project: ZooKeeper Issue Type: Bug Components: build Affects Versions: 3.3.3 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Blocker Fix For: 3.3.4 Attachments: ZOOKEEPER-1283.patch I tried to compile 3.3.3 or the current 3.3 branch head, in both cases using ant 1.8.2 fails, however 1.7.0 is successful here's the error: {noformat} Testsuite: org.apache.zookeeper.VerGenTest Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.009 sec Testcase: warning took 0.001 sec FAILED Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() junit.framework.AssertionFailedError: Class org.apache.zookeeper.VerGenTest has no public constructor TestCase(String name) or TestCase() {noformat} -- 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 # 2 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/2/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 85458 lines...] [junit] ensureOnly:[] [junit] 2011-11-03 05:53:40,385 - INFO [main:ClientBase@415] - STARTING server [junit] 2011-11-03 05:53:40,386 - 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/test1031751556819117794.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test1031751556819117794.junit.dir/version-2 [junit] 2011-11-03 05:53:40,386 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-03 05:53:40,387 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test1031751556819117794.junit.dir/version-2/snapshot.0 [junit] 2011-11-03 05:53:40,390 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] 2011-11-03 05:53:40,391 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] 2011-11-03 05:53:40,392 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:49172 [junit] 2011-11-03 05:53:40,392 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:49172 [junit] 2011-11-03 05:53:40,393 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2011-11-03 05:53:40,393 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:49172 (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] 2011-11-03 05:53:40,395 - INFO [main:ClientBase@422] - STOPPING server [junit] 2011-11-03 05:53:40,396 - INFO [ProcessThread:-1:PrepRequestProcessor@120] - PrepRequestProcessor exited loop! [junit] 2011-11-03 05:53:40,396 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2011-11-03 05:53:40,396 - INFO [main:FinalRequestProcessor@378] - shutdown of request processor complete [junit] 2011-11-03 05:53:40,397 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] ensureOnly:[] [junit] 2011-11-03 05:53:40,398 - INFO [main:ClientBase@415] - STARTING server [junit] 2011-11-03 05:53:40,399 - 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/test1031751556819117794.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test1031751556819117794.junit.dir/version-2 [junit] 2011-11-03 05:53:40,399 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2011-11-03 05:53:40,400 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test1031751556819117794.junit.dir/version-2/snapshot.b [junit] 2011-11-03 05:53:40,402 - INFO [main:FileTxnSnapLog@254] - Snapshotting: b [junit] 2011-11-03 05:53:40,404 - INFO [main:ClientBase@220] - connecting to 127.0.0.1 11221 [junit] 2011-11-03 05:53:40,405 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:49174 [junit] 2011-11-03 05:53:40,405 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:49174 [junit] 2011-11-03 05:53:40,406 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2011-11-03 05:53:40,407 - INFO [Thread-5:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:49174 (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
[jira] [Resolved] (BOOKKEEPER-15) Last modification time of a bookkeeper ledger
[ https://issues.apache.org/jira/browse/BOOKKEEPER-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dhruba borthakur resolved BOOKKEEPER-15. Resolution: Won't Fix Last modification time of a bookkeeper ledger - Key: BOOKKEEPER-15 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-15 Project: Bookkeeper Issue Type: Improvement Reporter: dhruba borthakur I would like to discuss how hard or easy it will be to implement a bookkeeper api that returns the last modification time of a ledger. This is related to ZOOKEEPER-465. -- 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