[jira] [Updated] (ZOOKEEPER-1264) FollowerResyncConcurrencyTest failing intermittently

2011-11-02 Thread Benjamin Reed (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Thomas Koch (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Thomas Koch
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hudson (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Sijie Guo (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Sijie Guo (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Thomas Koch (Reopened) (JIRA)

 [ 
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

2011-11-02 Thread Thomas Koch (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Thomas Koch (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Thomas Koch (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Benjamin Reed
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Thomas Koch

---
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

2011-11-02 Thread Camille Fournier
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

2011-11-02 Thread Benjamin Reed (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Benjamin Reed (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Camille Fournier (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Camille Fournier (Commented) (JIRA)

[ 
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

2011-11-02 Thread Patrick Hunt
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

2011-11-02 Thread Benjamin Reed (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Ted Dunning
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

2011-11-02 Thread Thomas Koch (Created) (JIRA)
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

2011-11-02 Thread Camille Fournier (Commented) (JIRA)

[ 
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

2011-11-02 Thread Patrick Hunt (Created) (JIRA)
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

2011-11-02 Thread Patrick Hunt (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Patrick Hunt (Created) (JIRA)
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Thomas Koch (Created) (JIRA)
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?)

2011-11-02 Thread Daniel Lord (Created) (JIRA)
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

2011-11-02 Thread Daniel Lord (Created) (JIRA)
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

2011-11-02 Thread Benjamin Reed (Commented) (JIRA)

[ 
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

2011-11-02 Thread Ted Dunning
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

2011-11-02 Thread Camille Fournier (Commented) (JIRA)

[ 
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

2011-11-02 Thread Patrick Hunt
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

2011-11-02 Thread Ted Dunning
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

2011-11-02 Thread Camille Fournier (Commented) (JIRA)

[ 
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

2011-11-02 Thread Camille Fournier (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Patrick Hunt (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Mahadev konar (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Patrick Hunt (Commented) (JIRA)

[ 
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

2011-11-02 Thread Hudson (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Benjamin Reed (Commented) (JIRA)

[ 
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.

2011-11-02 Thread Patrick Hunt (Updated) (JIRA)

 [ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Apache Jenkins Server
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!

2011-11-02 Thread Patrick Hunt
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.

2011-11-02 Thread Mahadev konar (Commented) (JIRA)

[ 
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

2011-11-02 Thread Benjamin Reed (Updated) (JIRA)

 [ 
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)

2011-11-02 Thread Patrick Hunt (Created) (JIRA)
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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)

2011-11-02 Thread Patrick Hunt (Updated) (JIRA)

 [ 
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)

2011-11-02 Thread Hadoop QA (Commented) (JIRA)

[ 
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

2011-11-02 Thread Apache Jenkins Server
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

2011-11-02 Thread dhruba borthakur (Resolved) (JIRA)

 [ 
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