Failed: ZOOKEEPER-1783 PreCommit Build #1678

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1783
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 936032 lines...]
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12607949/ZOOKEEPER-1783-ver2.patch
 [exec]   against trunk revision 1531061.
 [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 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/1678//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//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] 569cefa72c5832b78292fdc4645d03c31a7d919d 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:1623:
 exec returned: 1

Total time: 42 minutes 39 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1783
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
1 tests failed.
REGRESSION:  org.apache.zookeeper.test.ReadOnlyModeTest.testSeekForRwServer

Error Message:
Timeout occurred. Please note the time in the report does not reflect the time 
until the timeout.

Stack Trace:
junit.framework.AssertionFailedError: Timeout occurred. Please note the time in 
the report does not reflect the time until the timeout.




ZooKeeper-trunk-ibm6 - Build # 309 - Failure

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/ZooKeeper-trunk-ibm6/309/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 286956 lines...]
[junit] 2013-10-11 09:00:20,813 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop!
[junit] 2013-10-11 09:00:20,813 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited!
[junit] 2013-10-11 09:00:20,814 [myid:] - INFO  
[main:FinalRequestProcessor@442] - shutdown of request processor complete
[junit] 2013-10-11 09:00:20,815 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 09:00:20,816 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[]
[junit] 2013-10-11 09:00:20,818 [myid:] - INFO  [main:ClientBase@414] - 
STARTING server
[junit] 2013-10-11 09:00:20,818 [myid:] - INFO  [main:ZooKeeperServer@149] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7711029383278093110.junit.dir/version-2
 snapdir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7711029383278093110.junit.dir/version-2
[junit] 2013-10-11 09:00:20,819 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 3 selector thread(s), 48 worker threads, and 64 
kB direct buffers.
[junit] 2013-10-11 09:00:20,820 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2013-10-11 09:00:20,821 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7711029383278093110.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 09:00:20,824 [myid:] - INFO  [main:FileTxnSnapLog@297] - 
Snapshotting: 0xb to 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7711029383278093110.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 09:00:20,827 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 09:00:20,828 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:34084
[junit] 2013-10-11 09:00:20,829 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from 
/127.0.0.1:34084
[junit] 2013-10-11 09:00:20,829 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output
[junit] 2013-10-11 09:00:20,830 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client 
/127.0.0.1:34084 (no session established for client)
[junit] 2013-10-11 09:00:20,830 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[InMemoryDataTree, StandaloneServer_port]
[junit] 2013-10-11 09:00:20,834 [myid:] - INFO  [main:JMXEnv@105] - 
expect:InMemoryDataTree
[junit] 2013-10-11 09:00:20,834 [myid:] - INFO  [main:JMXEnv@108] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2013-10-11 09:00:20,834 [myid:] - INFO  [main:JMXEnv@105] - 
expect:StandaloneServer_port
[junit] 2013-10-11 09:00:20,835 [myid:] - INFO  [main:JMXEnv@108] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2013-10-11 09:00:20,835 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota
[junit] 2013-10-11 09:00:20,835 [myid:] - INFO  [main:ClientBase@451] - 
tearDown starting
[junit] 2013-10-11 09:00:20,937 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down
[junit] 2013-10-11 09:00:20,937 [myid:] - INFO  [main:ZooKeeper@777] - 
Session: 0x141a6bebeaa closed
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  [main:ClientBase@421] - 
STOPPING server
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-2:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2013-10-11 09:00:20,938 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 

ZooKeeper-trunk-solaris - Build # 697 - Still Failing

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/697/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 219946 lines...]
[junit] 2013-10-11 09:11:03,039 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2013-10-11 09:11:03,040 [myid:] - INFO  [main:ZooKeeperServer@428] 
- shutting down
[junit] 2013-10-11 09:11:03,040 [myid:] - INFO  
[main:SessionTrackerImpl@183] - Shutting down
[junit] 2013-10-11 09:11:03,040 [myid:] - INFO  
[main:PrepRequestProcessor@972] - Shutting down
[junit] 2013-10-11 09:11:03,041 [myid:] - INFO  
[main:SyncRequestProcessor@190] - Shutting down
[junit] 2013-10-11 09:11:03,041 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop!
[junit] 2013-10-11 09:11:03,041 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited!
[junit] 2013-10-11 09:11:03,041 [myid:] - INFO  
[main:FinalRequestProcessor@442] - shutdown of request processor complete
[junit] 2013-10-11 09:11:03,041 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 09:11:03,042 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[]
[junit] 2013-10-11 09:11:03,043 [myid:] - INFO  [main:ClientBase@414] - 
STARTING server
[junit] 2013-10-11 09:11:03,043 [myid:] - INFO  [main:ZooKeeperServer@149] 
- 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/test8357945759987.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test8357945759987.junit.dir/version-2
[junit] 2013-10-11 09:11:03,044 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2013-10-11 09:11:03,044 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2013-10-11 09:11:03,045 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test8357945759987.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 09:11:03,047 [myid:] - INFO  [main:FileTxnSnapLog@297] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test8357945759987.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 09:11:03,049 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 09:11:03,049 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:47742
[junit] 2013-10-11 09:11:03,050 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from 
/127.0.0.1:47742
[junit] 2013-10-11 09:11:03,050 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output
[junit] 2013-10-11 09:11:03,050 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client 
/127.0.0.1:47742 (no session established for client)
[junit] 2013-10-11 09:11:03,050 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[InMemoryDataTree, StandaloneServer_port]
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  [main:JMXEnv@105] - 
expect:InMemoryDataTree
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  [main:JMXEnv@108] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  [main:JMXEnv@105] - 
expect:StandaloneServer_port
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  [main:JMXEnv@108] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota
[junit] 2013-10-11 09:11:03,052 [myid:] - INFO  [main:ClientBase@451] - 
tearDown starting
[junit] 2013-10-11 09:11:03,130 [myid:] - INFO  [main:ZooKeeper@777] - 
Session: 0x141a6c88bc0 closed
[junit] 2013-10-11 09:11:03,130 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down
[junit] 2013-10-11 09:11:03,130 [myid:] - INFO  [main:ClientBase@421] - 
STOPPING server
[junit] 2013-10-11 09:11:03,131 [myid:] - INFO  

[jira] [Commented] (ZOOKEEPER-1777) Missing ephemeral nodes in one of the members of the ensemble

2013-10-11 Thread JIRA

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792479#comment-13792479
 ] 

Germán Blanco commented on ZOOKEEPER-1777:
--

I have noticed that ZOOKEEPER-1413 does solve part of the issues included here.
E.g. ZOOKEEPER-1413 solves the inconsistencies when joining an ensemble with a 
lower epoch (instead of the current behavior in branch 3.4, which is an 
infinite loop in the leader and the joining server). 
Any chances to consider ZOOKEEPER-1413 a bug fix instead of an improvement and 
include it in the 3.4 branch?

 Missing ephemeral nodes in one of the members of the ensemble
 -

 Key: ZOOKEEPER-1777
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1777
 Project: ZooKeeper
  Issue Type: Bug
  Components: quorum
Affects Versions: 3.4.5
 Environment: Linux, Java 1.7
Reporter: Germán Blanco
Assignee: Germán Blanco
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: logs_trunk.tar.gz, snaps.tar, ZOOKEEPER-1777-3.4.patch, 
 ZOOKEEPER-1777.patch, ZOOKEEPER-1777.patch, ZOOKEEPER-1777.tar.gz


 In a 3-servers ensemble, one of the followers doesn't see part of the 
 ephemeral nodes that are present in the leader and the other follower. 
 The 8 missing nodes in the follower that is not ok were created in the end 
 of epoch 1, the ensemble is running in epoch 2.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


ZooKeeper_branch33 - Build # 1101 - Failure

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/ZooKeeper_branch33/1101/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 9806 lines...]
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:567)
at hudson.model.Run.execute(Run.java:1603)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:246)
Caused by: hudson.remoting.ChannelClosedException: channel is already closed
at hudson.remoting.Channel.send(Channel.java:516)
at hudson.remoting.Request.call(Request.java:129)
at hudson.remoting.Channel.call(Channel.java:714)
at hudson.FilePath.act(FilePath.java:898)
... 13 more
Caused by: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2596)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1316)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at hudson.remoting.Command.readFrom(Command.java:92)
at 
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)
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.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at 
hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:714)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167)
at com.sun.proxy.$Proxy42.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:925)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:91)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:567)
at hudson.model.Run.execute(Run.java:1603)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:246)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: 
Unexpected termination of the channel
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:774)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2596)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1316)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at hudson.remoting.Command.readFrom(Command.java:92)
at 
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)



###
## FAILED TESTS (if any) 
##
No tests ran.

ZooKeeper-3.4-WinVS2008_java - Build # 321 - Still Failing

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/321/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 193966 lines...]
[junit] 2013-10-11 11:13:17,410 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@509] - EventThread shut down
[junit] 2013-10-11 11:13:17,502 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - 
NIOServerCnxn factory exited run method
[junit] 2013-10-11 11:13:17,603 [myid:] - INFO  [main:ZooKeeperServer@443] 
- shutting down
[junit] 2013-10-11 11:13:17,603 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2013-10-11 11:13:17,603 [myid:] - INFO  
[main:PrepRequestProcessor@761] - Shutting down
[junit] 2013-10-11 11:13:17,603 [myid:] - INFO  
[main:SyncRequestProcessor@190] - Shutting down
[junit] 2013-10-11 11:13:17,604 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2013-10-11 11:13:17,604 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited!
[junit] 2013-10-11 11:13:17,703 [myid:] - INFO  
[main:FinalRequestProcessor@415] - shutdown of request processor complete
[junit] 2013-10-11 11:13:17,704 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 11:13:18,000 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@162] - SessionTrackerImpl exited loop!
[junit] 2013-10-11 11:13:18,000 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@162] - SessionTrackerImpl exited loop!
[junit] 2013-10-11 11:13:18,698 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[]
[junit] 2013-10-11 11:13:18,702 [myid:] - INFO  [main:ZKTestCase$1@65] - 
FAILED testQuota
[junit] junit.framework.AssertionFailedError: expected:0 but was:1
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at junit.framework.Assert.failNotEquals(Assert.java:283)
[junit] at junit.framework.Assert.assertEquals(Assert.java:64)
[junit] at junit.framework.Assert.assertEquals(Assert.java:195)
[junit] at junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138)
[junit] at 
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417)
[junit] at 
org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:78)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
[junit] at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
[junit] at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
[junit] at 
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
[junit] at 
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
[junit] at 
org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
[junit] at 
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
[junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)
[junit] 2013-10-11 11:13:18,709 [myid:] - INFO  [main:ZKTestCase$1@55] - 
FINISHED testQuota
[junit] Tests run: 1, 

ZooKeeper-trunk-jdk7 - Build # 678 - Failure

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/ZooKeeper-trunk-jdk7/678/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 276746 lines...]
[junit] 2013-10-11 10:14:59,674 [myid:] - INFO  
[main:SessionTrackerImpl@183] - Shutting down
[junit] 2013-10-11 10:14:59,675 [myid:] - INFO  
[main:PrepRequestProcessor@972] - Shutting down
[junit] 2013-10-11 10:14:59,675 [myid:] - INFO  
[main:SyncRequestProcessor@190] - Shutting down
[junit] 2013-10-11 10:14:59,675 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop!
[junit] 2013-10-11 10:14:59,675 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited!
[junit] 2013-10-11 10:14:59,675 [myid:] - INFO  
[main:FinalRequestProcessor@442] - shutdown of request processor complete
[junit] 2013-10-11 10:14:59,676 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 10:14:59,676 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[]
[junit] 2013-10-11 10:14:59,677 [myid:] - INFO  [main:ClientBase@414] - 
STARTING server
[junit] 2013-10-11 10:14:59,677 [myid:] - INFO  [main:ZooKeeperServer@149] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3789054887110051816.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3789054887110051816.junit.dir/version-2
[junit] 2013-10-11 10:14:59,677 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2013-10-11 10:14:59,678 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2013-10-11 10:14:59,678 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3789054887110051816.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 10:14:59,680 [myid:] - INFO  [main:FileTxnSnapLog@297] - 
Snapshotting: 0xb to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3789054887110051816.junit.dir/version-2/snapshot.b
[junit] 2013-10-11 10:14:59,682 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2013-10-11 10:14:59,682 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:41660
[junit] 2013-10-11 10:14:59,683 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from 
/127.0.0.1:41660
[junit] 2013-10-11 10:14:59,683 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output
[junit] 2013-10-11 10:14:59,683 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client 
/127.0.0.1:41660 (no session established for client)
[junit] 2013-10-11 10:14:59,683 [myid:] - INFO  [main:JMXEnv@133] - 
ensureOnly:[InMemoryDataTree, StandaloneServer_port]
[junit] 2013-10-11 10:14:59,684 [myid:] - INFO  [main:JMXEnv@105] - 
expect:InMemoryDataTree
[junit] 2013-10-11 10:14:59,685 [myid:] - INFO  [main:JMXEnv@108] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2013-10-11 10:14:59,685 [myid:] - INFO  [main:JMXEnv@105] - 
expect:StandaloneServer_port
[junit] 2013-10-11 10:14:59,685 [myid:] - INFO  [main:JMXEnv@108] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2013-10-11 10:14:59,685 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota
[junit] 2013-10-11 10:14:59,685 [myid:] - INFO  [main:ClientBase@451] - 
tearDown starting
[junit] 2013-10-11 10:14:59,761 [myid:] - INFO  [main:ZooKeeper@777] - 
Session: 0x141a70316b8 closed
[junit] 2013-10-11 10:14:59,762 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down
[junit] 2013-10-11 10:14:59,762 [myid:] - INFO  [main:ClientBase@421] - 
STOPPING server
[junit] 2013-10-11 10:14:59,762 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2013-10-11 10:14:59,763 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2013-10-11 10:14:59,763 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method

RE: [jira] [Commented] (ZOOKEEPER-1742) make check doesn't work on macos

2013-10-11 Thread FPJ
Ben,

What are the tests that we would need to disable? If any have any concrete
insight here, could you please add to the jira?

Thanks,
-Flavio

 -Original Message-
 From: Benjamin Reed [mailto:br...@apache.org]
 Sent: 10 October 2013 04:22
 To: dev@zookeeper.apache.org
 Subject: Re: [jira] [Commented] (ZOOKEEPER-1742) make check doesn't
 work on macos
 
 i've been looking into the --wrap issue. the linker on osx just doesn't
support
 it, and the functionality is pretty magical. i think we should just
disable the
 tests that use them on osx
 
 
 On Wed, Oct 9, 2013 at 10:18 AM, Patrick Hunt (JIRA)
 j...@apache.orgwrote:
 
 
  [
  https://issues.apache.org/jira/browse/ZOOKEEPER-
 1742?page=com.atlassia
  n.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=
  13790630#comment-13790630]
 
  Patrick Hunt commented on ZOOKEEPER-1742:
  -
 
  Should we split these out? How do you want to handle it? The failing
  test is a blocker for 3.4.6 IMO.
 
   make check doesn't work on macos
   --
  
   Key: ZOOKEEPER-1742
   URL:
  https://issues.apache.org/jira/browse/ZOOKEEPER-1742
   Project: ZooKeeper
Issue Type: Bug
  Reporter: Flavio Junqueira
  Assignee: Benjamin Reed
   Fix For: 3.4.6, 3.5.0
  
  
   There are two problems I have spotted when running make check with
   the
  C client. First, it complains that the sleep call is not defined in
  two test files: tests/ZooKeeperQuorumServer.cc and
 tests/TestReconfigServer.cc.
  Including unistd.h works. The second problem is with linker options.
  It complains that --wrap is not a valid. I'm not sure how to deal
  with this one yet, since I'm not sure why we are using it.
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.1#6144)
 



[jira] [Commented] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792761#comment-13792761
 ] 

Patrick Hunt commented on ZOOKEEPER-1725:
-

[~shralex] is this something you can address?

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Priority: Minor

 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1725:


Fix Version/s: 3.5.0

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Priority: Minor
 Fix For: 3.5.0


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1703) Please add instructions for running the tutorial

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1703:


Labels: newbie  (was: )

 Please add instructions for running the tutorial
 

 Key: ZOOKEEPER-1703
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1703
 Project: ZooKeeper
  Issue Type: New Feature
  Components: documentation
Affects Versions: 3.4.5
 Environment: tutorial 
 http://zookeeper.apache.org/doc/r3.2.2/zookeeperTutorial.html
Reporter: Hayden Schultz
Priority: Minor
  Labels: newbie

 There's no instructions for running the tutorial. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Alexander Shraer (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792771#comment-13792771
 ] 

Alexander Shraer commented on ZOOKEEPER-1725:
-

Hi Patrick, 

I have my hands full with other JIRAs, would be good if someone else takes 
this. 

Alex

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Priority: Minor
 Fix For: 3.5.0


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1077) C client lib doesn't build on Solairs

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1077:


 Priority: Critical  (was: Minor)
Fix Version/s: 3.5.0
   3.4.6

 C client lib doesn't build on Solairs
 -

 Key: ZOOKEEPER-1077
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1077
 Project: ZooKeeper
  Issue Type: Bug
  Components: build, c client
Affects Versions: 3.3.4
 Environment: uname -a: SunOS [redacted] 5.10 Generic_142910-17 i86pc 
 i386 i86pc
 GNU toolchain (gcc 3.4.3, GNU Make etc.)
Reporter: Tadeusz Andrzej Kadłubowski
Assignee: Justin SB
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: zookeeper.patch


 Hello,
 Some minor trouble with building ZooKeeper C client library on 
 Sun^H^H^HOracle Solaris 5.10.
 1. You need to link against -lnsl -lsocket
 2. ctime_r needs a buffer size. The signature is: char *ctime_r(const time_t 
 *clock, char *buf, int buflen)
 3. In zk_log.c you need to manually cast pid_t to int (-Werror can be 
 cumbersome ;) )
 4. getpwuid_r()returns pointer to struct passwd, which works as the last 
 parameter on Linux.
 Solaris signature: struct passwd *getpwuid_r(uid_t  uid,  struct  passwd  
 *pwd, char *buffer, int  buflen); 
 Linux signature: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buf, 
 size_t buflen, struct passwd **result);



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1077) C client lib doesn't build on Solairs

2013-10-11 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792773#comment-13792773
 ] 

Patrick Hunt commented on ZOOKEEPER-1077:
-

Looks like issue on solaris with the c client as well. ZOOKEEPER-1077  
ZOOKEEPER-1742

 C client lib doesn't build on Solairs
 -

 Key: ZOOKEEPER-1077
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1077
 Project: ZooKeeper
  Issue Type: Bug
  Components: build, c client
Affects Versions: 3.3.4
 Environment: uname -a: SunOS [redacted] 5.10 Generic_142910-17 i86pc 
 i386 i86pc
 GNU toolchain (gcc 3.4.3, GNU Make etc.)
Reporter: Tadeusz Andrzej Kadłubowski
Assignee: Justin SB
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: zookeeper.patch


 Hello,
 Some minor trouble with building ZooKeeper C client library on 
 Sun^H^H^HOracle Solaris 5.10.
 1. You need to link against -lnsl -lsocket
 2. ctime_r needs a buffer size. The signature is: char *ctime_r(const time_t 
 *clock, char *buf, int buflen)
 3. In zk_log.c you need to manually cast pid_t to int (-Werror can be 
 cumbersome ;) )
 4. getpwuid_r()returns pointer to struct passwd, which works as the last 
 parameter on Linux.
 Solaris signature: struct passwd *getpwuid_r(uid_t  uid,  struct  passwd  
 *pwd, char *buffer, int  buflen); 
 Linux signature: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buf, 
 size_t buflen, struct passwd **result);



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Failed: ZOOKEEPER-1357 PreCommit Build #1679

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1679/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 457 lines...]
 [exec] patching file src/c/include/proto.h
 [exec] Hunk #1 FAILED at 36.
 [exec] 1 out of 1 hunk FAILED -- saving rejects to file 
src/c/include/proto.h.rej
 [exec] (Stripping trailing CRs from patch.)
 [exec] patching file src/contrib/fatjar/conf/mainClasses
 [exec] (Stripping trailing CRs from patch.)
 [exec] patching file src/zookeeper.jute
 [exec] Hunk #1 FAILED at 92.
 [exec] Hunk #2 FAILED at 201.
 [exec] 2 out of 2 hunks FAILED -- saving rejects to file 
src/zookeeper.jute.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/12509972/reconfig-8-jan.patch
 [exec]   against trunk revision 1531061.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 57 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/1679//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] cfe251fd8169dc8f59e78fe8610c80013a5ea861 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:1623:
 exec returned: 1

Total time: 45 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1357
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792774#comment-13792774
 ] 

Hadoop QA commented on ZOOKEEPER-1357:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12509972/reconfig-8-jan.patch
  against trunk revision 1531061.

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 57 new or modified tests.

-1 patch.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1679//console

This message is automatically generated.

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Alexander Shraer
Priority: Minor
 Attachments: reconfig-8-jan.patch


 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (ZOOKEEPER-278) Create a test jar

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt resolved ZOOKEEPER-278.


Resolution: Implemented

A test jar is currently provided in our Apache Nexus maven artifact repository.

 Create a test jar
 -

 Key: ZOOKEEPER-278
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-278
 Project: ZooKeeper
  Issue Type: Improvement
  Components: tests
Reporter: Nitay Joffe
Priority: Minor

 I am working on integrating ZooKeeper into HBase. I've found myself copying a 
 lot of the test infrastructure code from places like zk.t.QuorumTest to 
 create classes like MiniZooKeeper so that I can test my new additions in 
 HBase. I think things would be a lot easier if we shipped a ZooKeeper test 
 jar for others to use. Additionally, I think we should clean up the test code 
 a bit so that the tests use some common infrastructure rather than each doing 
 its own setup/teardown of a ZK cluster. I believe this is how things are done 
 for testing Hadoop things HBase.
 For more context, see hbase-1144.patch in 
 https://issues.apache.org/jira/browse/HBASE-1144
 I would do this myself but I can't currently contribute to Apache projects 
 other than HBase because of company issues. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1622) session ids will be negative in the year 2022

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1622:


Assignee: Eric Newton

 session ids will be negative in the year 2022
 -

 Key: ZOOKEEPER-1622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1622
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Eric Newton
Assignee: Eric Newton
Priority: Trivial

 Someone decided to use a large number for their myid file.  This cause 
 session ids to go negative, and our software (Apache Accumulo) did not handle 
 this very well.  While diagnosing the problem, I noticed this in SessionImpl:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 When the 40th bit in System.currentTimeMillis() is a one, sign extension will 
 fill the upper 8 bytes of nextSid, and id will not make the session id 
 unique.  I recommend changing the right shift to the logical shift:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 But, we have until the year 2022 before we have to worry about it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1622) session ids will be negative in the year 2022

2013-10-11 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792777#comment-13792777
 ] 

Patrick Hunt commented on ZOOKEEPER-1622:
-

[~ecn] could you submit a patch? Thanks.

 session ids will be negative in the year 2022
 -

 Key: ZOOKEEPER-1622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1622
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Eric Newton
Assignee: Eric Newton
Priority: Trivial

 Someone decided to use a large number for their myid file.  This cause 
 session ids to go negative, and our software (Apache Accumulo) did not handle 
 this very well.  While diagnosing the problem, I noticed this in SessionImpl:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 When the 40th bit in System.currentTimeMillis() is a one, sign extension will 
 fill the upper 8 bytes of nextSid, and id will not make the session id 
 unique.  I recommend changing the right shift to the logical shift:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 But, we have until the year 2022 before we have to worry about it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1610) Some classes are using == or != to compare Long/String objects instead of .equals()

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1610:


Priority: Critical  (was: Trivial)

 Some classes are using == or != to compare Long/String objects instead of 
 .equals()
 ---

 Key: ZOOKEEPER-1610
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1610
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client, quorum
Affects Versions: 3.4.5, 3.5.0
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1610.patch


 The classes org.apache.zookeeper.client.ZooKeeperSaslClient.java and 
 org.apache.zookeeper.server.quorum.flexible.QuorumHierarchical.java compare 
 Strings and/or Longs using referential equality.
 Usually, this is not a problem because the Longs are cached and Strings are 
 interned, but I myself  had problems with those kind of comparisons in the 
 past because one production JVM didn't reused the objects.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1695) Inconsistent error code and type for new errors introduced by dynamic reconfiguration

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1695:


 Priority: Blocker  (was: Trivial)
Fix Version/s: 3.5.0

[~shralex] can we get a patch to address this? seems trivial to fix now, save 
headache later. Thanks.

 Inconsistent error code and type for new errors introduced by dynamic 
 reconfiguration  
 ---

 Key: ZOOKEEPER-1695
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1695
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0
Reporter: Thawan Kooburat
Priority: Blocker
 Fix For: 3.5.0


 From KeeperException.Code, RECONFIGINPROGRESS and NEWCONFIGNOQUORUM are 
 declared as system errors. However, their error code suggested that they are 
 API errors. 
 We either need to move it to the right type or use the code from the right 
 range



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (ZOOKEEPER-1527) Correct the documentation of the args for the JavaExample doc

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt resolved ZOOKEEPER-1527.
-

Resolution: Duplicate

dup of ZOOKEEPER-1526

 Correct the documentation of the args for the JavaExample doc
 -

 Key: ZOOKEEPER-1527
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1527
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Warren Turkal
Priority: Trivial

 I added another listitem documenting the filename arg of the JavaExample code.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (ZOOKEEPER-1249) jline should be an optional maven dependency

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt resolved ZOOKEEPER-1249.
-

Resolution: Duplicate

Fixed in ZOOKEEPER-1655

 jline should be an optional maven dependency
 

 Key: ZOOKEEPER-1249
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1249
 Project: ZooKeeper
  Issue Type: Improvement
  Components: build
Reporter: David Smiley
Priority: Trivial

 When a project adds a maven dependency to zookeeper, they probably don't want 
 the jline dependency.  jline should have optionaltrue/optional in 
 zookeeper's maven pom.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that

2013-10-11 Thread Alexander Shraer (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792789#comment-13792789
 ] 

Alexander Shraer commented on ZOOKEEPER-1357:
-

Part of this was solved by ZOOKEEPER-1522 (the part of correctly terminating 
leaderThread).
The hard-wired ports are still there. I can make a patch.

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Alexander Shraer
Priority: Minor

 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that th

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1357:


Attachment: (was: reconfig-8-jan.patch)

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Alexander Shraer
Priority: Minor

 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Assigned] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that t

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer reassigned ZOOKEEPER-1357:
---

Assignee: Alexander Shraer

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
  Components: tests
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Assignee: Alexander Shraer
Priority: Minor
 Attachments: ZOOKEEPER-1357.patch


 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that th

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1357:


Attachment: ZOOKEEPER-1357.patch

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
  Components: tests
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Priority: Minor
 Attachments: ZOOKEEPER-1357.patch


 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that th

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1357:


  Component/s: tests
Affects Version/s: 3.5.0

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
  Components: tests
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Assignee: Alexander Shraer
Priority: Minor
 Attachments: ZOOKEEPER-1357.patch


 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1622) session ids will be negative in the year 2022

2013-10-11 Thread Eric Newton (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Newton updated ZOOKEEPER-1622:
---

Attachment: ZOOKEEPER-1622.patch

 session ids will be negative in the year 2022
 -

 Key: ZOOKEEPER-1622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1622
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Eric Newton
Assignee: Eric Newton
Priority: Trivial
 Attachments: ZOOKEEPER-1622.patch


 Someone decided to use a large number for their myid file.  This cause 
 session ids to go negative, and our software (Apache Accumulo) did not handle 
 this very well.  While diagnosing the problem, I noticed this in SessionImpl:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 When the 40th bit in System.currentTimeMillis() is a one, sign extension will 
 fill the upper 8 bytes of nextSid, and id will not make the session id 
 unique.  I recommend changing the right shift to the logical shift:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 But, we have until the year 2022 before we have to worry about it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1695) Inconsistent error code and type for new errors introduced by dynamic reconfiguration

2013-10-11 Thread Alexander Shraer (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792804#comment-13792804
 ] 

Alexander Shraer commented on ZOOKEEPER-1695:
-

You mean the fact that the error number is  100 ? I don't think that the 
numeric value of the error has any significance, is this described anywhere ? 
For example EphemeralOnLocalSession was just added after reconfig errors with 
the value 122. 

The comment there says

 /** This interface contains the original static final int constants
 * which have now been replaced with an enumeration in Code. 
 

 Inconsistent error code and type for new errors introduced by dynamic 
 reconfiguration  
 ---

 Key: ZOOKEEPER-1695
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1695
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0
Reporter: Thawan Kooburat
Priority: Blocker
 Fix For: 3.5.0


 From KeeperException.Code, RECONFIGINPROGRESS and NEWCONFIGNOQUORUM are 
 declared as system errors. However, their error code suggested that they are 
 API errors. 
 We either need to move it to the right type or use the code from the right 
 range



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Failed: ZOOKEEPER-1610 PreCommit Build #1680

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1610
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 311847 lines...]
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12562389/ZOOKEEPER-1610.patch
 [exec]   against trunk revision 1531061.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] -1 tests included.  The patch doesn't appear to include any new 
or modified tests.
 [exec] Please justify why no new tests are needed 
for this patch.
 [exec] Also please list what manual steps were 
performed to verify this patch.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//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] 71e0bc74fb5c3b0b2af0a2a40a6e7582f3a85a91 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:1623:
 exec returned: 1

Total time: 33 minutes 18 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1610
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1610) Some classes are using == or != to compare Long/String objects instead of .equals()

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792822#comment-13792822
 ] 

Hadoop QA commented on ZOOKEEPER-1610:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12562389/ZOOKEEPER-1610.patch
  against trunk revision 1531061.

+1 @author.  The patch does not contain any @author tags.

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) 
warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1680//console

This message is automatically generated.

 Some classes are using == or != to compare Long/String objects instead of 
 .equals()
 ---

 Key: ZOOKEEPER-1610
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1610
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client, quorum
Affects Versions: 3.4.5, 3.5.0
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1610.patch


 The classes org.apache.zookeeper.client.ZooKeeperSaslClient.java and 
 org.apache.zookeeper.server.quorum.flexible.QuorumHierarchical.java compare 
 Strings and/or Longs using referential equality.
 Usually, this is not a problem because the Longs are cached and Strings are 
 interned, but I myself  had problems with those kind of comparisons in the 
 past because one production JVM didn't reused the objects.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (BOOKKEEPER-657) Journal Improvement

2013-10-11 Thread Ivan Kelly (JIRA)

 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Kelly updated BOOKKEEPER-657:
--

Attachment: 0001-BOOKKEEPER-657-Journal-Improvement.patch

Needed a rebase. Patch is good. +1. Push it in if you consider the rebase ok 
(there's no actual changes in it).

 Journal Improvement
 ---

 Key: BOOKKEEPER-657
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-657
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-657-Journal-Improvement.patch, 
 BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, 
 BOOKKEEPER-657.patch


 separated force write thread, better group commit strategy on latency and 
 throughput.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Success: ZOOKEEPER-1357 PreCommit Build #1681

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1681/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 310752 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/12608026/ZOOKEEPER-1357.patch
 [exec]   against trunk revision 1531061.
 [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/1681//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1681//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1681//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] 2fcc097d10eb15c7ea84b18e1aca15f3f0a94af9 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 33 minutes 19 seconds
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1357
Email was triggered for: Success
Sending email for trigger: Success



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1357) Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port for leader in two different tests. The second test periodically fails complaining that

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792869#comment-13792869
 ] 

Hadoop QA commented on ZOOKEEPER-1357:
--

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12608026/ZOOKEEPER-1357.patch
  against trunk revision 1531061.

+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/1681//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1681//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1681//console

This message is automatically generated.

 Zab1_0Test uses hard-wired port numbers. Specifically, it uses the same port 
 for leader in two different tests. The second test periodically fails 
 complaining that the port is still in use.
 -

 Key: ZOOKEEPER-1357
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1357
 Project: ZooKeeper
  Issue Type: Bug
  Components: tests
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Assignee: Alexander Shraer
Priority: Minor
 Attachments: ZOOKEEPER-1357.patch


 Here's what I get:
 Testcase: testLeaderInConnectingFollowers took 34.117 sec
 Testcase: testLastAcceptedEpoch took 0.047 sec- new 
 test added in ZK-1343
 Testcase: testLeaderInElectingFollowers took 0.004 sec
 Caused an ERROR
 Address already in use
 java.net.BindException: Address already in use
 at java.net.PlainSocketImpl.socketBind(Native Method)
 at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
 at java.net.ServerSocket.bind(ServerSocket.java:328)
 at java.net.ServerSocket.init(ServerSocket.java:194)
 at java.net.ServerSocket.init(ServerSocket.java:106)
 at org.apache.zookeeper.server.quorum.Leader.init(Leader.java:220)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.createLeader(Zab1_0Test.java:711)
 at 
 org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderInElectingFollowers(Zab1_0Test.java:225)
 Testcase: testNormalFollowerRun took 29.128 sec
 Testcase: testNormalRun took 25.158 sec
 Testcase: testLeaderBehind took 25.148 sec
 Testcase: testAbandonBeforeACKEpoch took 34.029 sec
 My guess is that testLastAcceptedEpoch doesn't properly close the connection 
 before testLeaderInElectingFollowers starts.
 I propose to add 
 if (leadThread != null) {
 leadThread.interrupt();
 leadThread.join();
 }   
 to the test.
 In addition, I propose to change the hard-wired ports in Zab1_0Test to use 
 Portassignment.unique() as done in other tests. If I understand correctly the 
 static counter used in unique() to assign ports is initialized once per test 
 file, so it would also prevent the problem I'm seeing here of two tests in 
 the same file trying to use the same port. 
 The error can be reproduced using the attached patch (for some reason I don't 
 see the problem in the trunk).



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-657) Journal Improvement

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792874#comment-13792874
 ] 

Hadoop QA commented on BOOKKEEPER-657:
--

Testing JIRA BOOKKEEPER-657


Patch 
[0001-BOOKKEEPER-657-Journal-Improvement.patch|https://issues.apache.org/jira/secure/attachment/12608032/0001-BOOKKEEPER-657-Journal-Improvement.patch]
 downloaded at Fri Oct 11 17:22:25 UTC 2013



{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than 
120
.{color:green}+1{color} the patch does adds/modifies 16 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT 
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc 
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac 
warnings
{color:green}+1 FINDBUGS{color}
.{color:green}+1{color} the patch does not seem to introduce new Findbugs 
warnings
{color:green}+1 TESTS{color}
.Tests run: 880
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch 


{color:green}*+1 Overall result, good!, no -1s*{color}


The full output of the test-patch run is available at

.   https://builds.apache.org/job/bookkeeper-trunk-precommit-build/509/

 Journal Improvement
 ---

 Key: BOOKKEEPER-657
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-657
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-657-Journal-Improvement.patch, 
 BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, 
 BOOKKEEPER-657.patch


 separated force write thread, better group commit strategy on latency and 
 throughput.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1725:


Attachment: ZOOKEEPER-1725.patch

attached patch seems to solve the issue

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1725:


Attachment: ZOOKEEPER-1357.patch

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1725:


Attachment: (was: ZOOKEEPER-1357.patch)

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1622) session ids will be negative in the year 2022

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792910#comment-13792910
 ] 

Hadoop QA commented on ZOOKEEPER-1622:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12608028/ZOOKEEPER-1622.patch
  against trunk revision 1531061.

+1 @author.  The patch does not contain any @author tags.

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) 
warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//console

This message is automatically generated.

 session ids will be negative in the year 2022
 -

 Key: ZOOKEEPER-1622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1622
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.0, 3.5.0
Reporter: Eric Newton
Assignee: Eric Newton
Priority: Trivial
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1622.patch


 Someone decided to use a large number for their myid file.  This cause 
 session ids to go negative, and our software (Apache Accumulo) did not handle 
 this very well.  While diagnosing the problem, I noticed this in SessionImpl:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 When the 40th bit in System.currentTimeMillis() is a one, sign extension will 
 fill the upper 8 bytes of nextSid, and id will not make the session id 
 unique.  I recommend changing the right shift to the logical shift:
 {noformat}
public static long initializeNextSession(long id) {
 long nextSid = 0;
 nextSid = (System.currentTimeMillis()  24)  8;
 nextSid =  nextSid | (id 56);
 return nextSid;
 }
 {noformat}
 But, we have until the year 2022 before we have to worry about it.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Failed: ZOOKEEPER-1622 PreCommit Build #1682

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1622
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 311227 lines...]
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12608028/ZOOKEEPER-1622.patch
 [exec]   against trunk revision 1531061.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] -1 tests included.  The patch doesn't appear to include any new 
or modified tests.
 [exec] Please justify why no new tests are needed 
for this patch.
 [exec] Also please list what manual steps were 
performed to verify this patch.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1682//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] ab6ac2b5050fb06fdce64c18a0e29d332fb9dbdb 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:1623:
 exec returned: 1

Total time: 33 minutes 12 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1622
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792946#comment-13792946
 ] 

Hadoop QA commented on ZOOKEEPER-1725:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12608046/ZOOKEEPER-1725.patch
  against trunk revision 1531061.

+1 @author.  The patch does not contain any @author tags.

-1 tests included.  The patch doesn't appear to include any new or modified 
tests.
Please justify why no new tests are needed for this 
patch.
Also please list what manual steps were performed to 
verify this patch.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs (version 1.3.9) 
warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//console

This message is automatically generated.

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Failed: ZOOKEEPER-1725 PreCommit Build #1683

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 294397 lines...]
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12608046/ZOOKEEPER-1725.patch
 [exec]   against trunk revision 1531061.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] -1 tests included.  The patch doesn't appear to include any new 
or modified tests.
 [exec] Please justify why no new tests are needed 
for this patch.
 [exec] Also please list what manual steps were 
performed to verify this patch.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1683//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] d388970a4b30a142bebe1c4676371db91d326707 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:1623:
 exec returned: 1

Total time: 33 minutes 41 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1725
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Updated] (ZOOKEEPER-1610) Some classes are using == or != to compare Long/String objects instead of .equals()

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1610:


Attachment: ZOOKEEPER-1610-br34.patch

 Some classes are using == or != to compare Long/String objects instead of 
 .equals()
 ---

 Key: ZOOKEEPER-1610
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1610
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client, quorum
Affects Versions: 3.4.5, 3.5.0
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1610-br34.patch, ZOOKEEPER-1610.patch


 The classes org.apache.zookeeper.client.ZooKeeperSaslClient.java and 
 org.apache.zookeeper.server.quorum.flexible.QuorumHierarchical.java compare 
 Strings and/or Longs using referential equality.
 Usually, this is not a problem because the Longs are cached and Strings are 
 interned, but I myself  had problems with those kind of comparisons in the 
 past because one production JVM didn't reused the objects.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state

2013-10-11 Thread Flavio Junqueira (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793042#comment-13793042
 ] 

Flavio Junqueira commented on ZOOKEEPER-1558:
-

Ok, I'll produce a new patch for 3.4. I think it would be best to simply get 
ZOOKEEPER-1549 in. I've been ignoring it just because I'm focusing on the 3.4.6 
release.

 Leader should not snapshot uncommitted state
 

 Key: ZOOKEEPER-1558
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: quorum
Affects Versions: 3.4.6
Reporter: Flavio Junqueira
Assignee: Flavio Junqueira
Priority: Blocker
 Fix For: 3.4.6

 Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, 
 ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch


 Leader currently takes a snapshot when it calls loadData in the beginning of 
 the lead() method. The loaded data, however, may contain uncommitted state.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1149) users cannot migrate from 3.4-3.3-3.4 server code against a single datadir

2013-10-11 Thread Patrick Hunt (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793071#comment-13793071
 ] 

Patrick Hunt commented on ZOOKEEPER-1149:
-

Note to future searchers, if you see something like this error it's 
potentially/likely this issue:

{noformat}
2013-10-11 08:11:37,319 ERROR org.apache.zookeeper.server.quorum.QuorumPeer: 
Unable to load database on disk
java.io.IOException: The current epoch, 4, is older than the last zxid, 
97270057040
{noformat}

 users cannot migrate from 3.4-3.3-3.4 server code against a single datadir
 

 Key: ZOOKEEPER-1149
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1149
 Project: ZooKeeper
  Issue Type: Task
  Components: server
Affects Versions: 3.4.0, 3.5.0
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Blocker
 Fix For: 3.4.0, 3.5.0


 3.4 is checking acceptedEpoch/currentEpoch files against the snap/log files 
 in datadir. These files are new in 3.4. If they don't exist the server will 
 create them, however if they do exist the server will validate them.
 As a result if a user 
 1) upgrades from 3.3 to 3.4 this is fine
 2) downgrades from 3.4 to 3.3 this is also fine (3.3 ignores these files)
 3) however, 3.4-3.3-3.4 fails because 3.4 will see invalid *Epoch files in 
 the datadir (as 3.3 would have ignored them, applying changes to snap/log w/o 
 updating them)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1715) Upgrade netty version

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1715:


Attachment: ZOOKEEPER-1715-v3.patch

Updated to upgrade to 3.7.0.Final

 Upgrade netty version
 -

 Key: ZOOKEEPER-1715
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1715
 Project: ZooKeeper
  Issue Type: Improvement
Affects Versions: 3.4.5
 Environment: zookeeper 3.4.5 uses netty 3.2.2, which was released in 
 August 2010.  The latest version of netty is 3.6.6 released May 2013.  
 Zookeeper should consider upgrading.
Reporter: Sean Bridges
Assignee: Sean Bridges
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1715-2.patch, zookeeper-1715.patch, 
 ZOOKEEPER-1715.patch, ZOOKEEPER-1715-v3.patch


 Upgrade netty version



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1398) zkpython corrupts session passwords that contain nulls

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1398:


Priority: Critical  (was: Major)

 zkpython corrupts session passwords that contain nulls
 --

 Key: ZOOKEEPER-1398
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1398
 Project: ZooKeeper
  Issue Type: Bug
  Components: c client, contrib-bindings
Affects Versions: 3.3.4
Reporter: Mike Lundy
Assignee: Mike Lundy
Priority: Critical
 Attachments: 0001-make-sure-the-client-password-isn-t-corrupted.patch


 If the session password contains a nul character (\0), it will be mutated as 
 it is passed to python. zkpython currently uses the ParseArgs flag that stops 
 on nul.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1077) C client lib doesn't build on Solaris

2013-10-11 Thread Patrick Hunt (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Patrick Hunt updated ZOOKEEPER-1077:


Summary: C client lib doesn't build on Solaris  (was: C client lib doesn't 
build on Solairs)

 C client lib doesn't build on Solaris
 -

 Key: ZOOKEEPER-1077
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1077
 Project: ZooKeeper
  Issue Type: Bug
  Components: build, c client
Affects Versions: 3.3.4
 Environment: uname -a: SunOS [redacted] 5.10 Generic_142910-17 i86pc 
 i386 i86pc
 GNU toolchain (gcc 3.4.3, GNU Make etc.)
Reporter: Tadeusz Andrzej Kadłubowski
Assignee: Justin SB
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: zookeeper.patch


 Hello,
 Some minor trouble with building ZooKeeper C client library on 
 Sun^H^H^HOracle Solaris 5.10.
 1. You need to link against -lnsl -lsocket
 2. ctime_r needs a buffer size. The signature is: char *ctime_r(const time_t 
 *clock, char *buf, int buflen)
 3. In zk_log.c you need to manually cast pid_t to int (-Werror can be 
 cumbersome ;) )
 4. getpwuid_r()returns pointer to struct passwd, which works as the last 
 parameter on Linux.
 Solaris signature: struct passwd *getpwuid_r(uid_t  uid,  struct  passwd  
 *pwd, char *buffer, int  buflen); 
 Linux signature: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buf, 
 size_t buflen, struct passwd **result);



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky

2013-10-11 Thread Thawan Kooburat (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793183#comment-13793183
 ] 

Thawan Kooburat commented on ZOOKEEPER-1793:


Alex,  where do you see that test is flaky? These builds look ok to me 
(https://builds.apache.org/job/ZooKeeper-trunk/, 
https://builds.apache.org/job/ZooKeeper_branch34/)

 Zab1_0Test.testNormalObserverRun() is flaky
 ---

 Key: ZOOKEEPER-1793
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
 Project: ZooKeeper
  Issue Type: Bug
  Components: quorum, server, tests
Reporter: Alexander Shraer
Assignee: Thawan Kooburat

 not sure if this is due to a known issue or not.
 // check and make sure the change is persisted
 zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
 lastZxid = zkDb2.loadDataBase();
 Assert.assertEquals(data2, new String(zkDb2.getData(/foo, stat, null)));
 this assert periodically (once every 3 runs of the test or so) fails saying 
 that  getData returns data1 and not data2.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky

2013-10-11 Thread Alexander Shraer (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793188#comment-13793188
 ] 

Alexander Shraer commented on ZOOKEEPER-1793:
-

Hi Thawan,

I'm running ant test -Dtestcase=Zab1_0Test on my Mac with trunk, and it fails 
with the error above once every 3-4 runs

Thanks
Alex

 Zab1_0Test.testNormalObserverRun() is flaky
 ---

 Key: ZOOKEEPER-1793
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
 Project: ZooKeeper
  Issue Type: Bug
  Components: quorum, server, tests
Reporter: Alexander Shraer
Assignee: Thawan Kooburat

 not sure if this is due to a known issue or not.
 // check and make sure the change is persisted
 zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
 lastZxid = zkDb2.loadDataBase();
 Assert.assertEquals(data2, new String(zkDb2.getData(/foo, stat, null)));
 this assert periodically (once every 3 runs of the test or so) fails saying 
 that  getData returns data1 and not data2.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Alexander Shraer (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Shraer updated ZOOKEEPER-1725:


Attachment: ZOOKEEPER-1725-ver1.patch

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch, ZOOKEEPER-1725-ver1.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


The problem of using c binding function

2013-10-11 Thread 吴腾飞
Hi

 

I using c client binding fuction zoo_aget,the passed data cause problem.

 

ZOOAPI int zoo_aget(zhandle_t *zh,const char *path,int
watch,data_completion_t completion,const void *data)

 

1.Using like this is ok:

 

int ret = zoo_aget(zkhandle, path,0,DataCompletion,” zoo_aget”);

DataCompletion:

DataCompletion(int rc, const char *value, int value_len, const struct Stat
*stat, const void *data)

{

  Coutdataendl;//out put is :zoo_aget

}

 

2.But this is no right:

Char* data = “zoo_aget”;

int ret = zoo_aget(zkhandle, path,0,DataCompletion, data);

DataCompletion:

DataCompletion(int rc, const char *value, int value_len, const struct Stat
*stat, const void *data)

{

  Coutdataendl;//out put is not zoo_aget

}

 

Why I in 2 can not got correct output?Using zoo_axxx,pass data also the same
question.

 

Thanks,

 

Albert Wu.



Success: ZOOKEEPER-1725 PreCommit Build #1685

2013-10-11 Thread Apache Jenkins Server
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1685/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 305187 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/12608128/ZOOKEEPER-1725-ver1.patch
 [exec]   against trunk revision 1531444.
 [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/1685//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1685//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1685//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] 904285e1ddc39069d126c431e1809366887066a1 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 32 minutes 50 seconds
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1725
Email was triggered for: Success
Sending email for trigger: Success



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793223#comment-13793223
 ] 

Hadoop QA commented on ZOOKEEPER-1725:
--

+1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12608128/ZOOKEEPER-1725-ver1.patch
  against trunk revision 1531444.

+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/1685//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1685//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1685//console

This message is automatically generated.

 Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
 -

 Key: ZOOKEEPER-1725
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Justin SB
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1725.patch, ZOOKEEPER-1725-ver1.patch


 When writing the dynamic configuration out, Zookeeper writes out hostnames, 
 even if an IP address is supplied.  These may not correctly round-trip (e.g. 
 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 
 and another IP address).
 This isn't actually causing problems for me right now, but seems very likely 
 to cause hard-to-track-down problems in future.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-658) ledger cache refactor

2013-10-11 Thread Sijie Guo (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792393#comment-13792393
 ] 

Sijie Guo commented on BOOKKEEPER-658:
--

+1 for the new patch from Ivan. committing.

 ledger cache refactor
 -

 Key: BOOKKEEPER-658
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-658
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-658-ledger-cache-refactor.patch, 
 BOOKKEEPER-658.patch


 refactor ledger cache to separate in-memory page management from persistent 
 management.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-658) ledger cache refactor

2013-10-11 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792423#comment-13792423
 ] 

Hudson commented on BOOKKEEPER-658:
---

SUCCESS: Integrated in bookkeeper-trunk #392 (See 
[https://builds.apache.org/job/bookkeeper-trunk/392/])
BOOKKEEPER-658: ledger cache refactor (Robin Dhamankar via sijie) (sijie: rev 
1531203)
* /zookeeper/bookkeeper/trunk/CHANGES.txt
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/BookieShell.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/FileInfo.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexInMemPageMgr.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexPersistenceMgr.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/LedgerCacheImpl.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/BookieJournalTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/LedgerCacheTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/UpgradeTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/AuditorPeriodicCheckTest.java


 ledger cache refactor
 -

 Key: BOOKKEEPER-658
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-658
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-658-ledger-cache-refactor.patch, 
 BOOKKEEPER-658.patch


 refactor ledger cache to separate in-memory page management from persistent 
 management.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Build failed in Jenkins: bookkeeper-trunk #393

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/bookkeeper-trunk/393/

--
[...truncated 444 lines...]
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ 
hedwig-protocol ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 6 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
hedwig-protocol ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/src/test/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ 
hedwig-protocol ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.9:test (default-test) @ hedwig-protocol ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ hedwig-protocol ---
[INFO] Building jar: 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/hedwig-protocol-4.3.0-SNAPSHOT.jar
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:findbugs (findbugs) @ hedwig-protocol ---
[INFO] Fork Value is true
[INFO] Done FindBugs Analysis
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol ---
[INFO] BugInstance size is 0
[INFO] Error size is 0
[INFO] No errors/warnings found
[INFO] 
[INFO] 
[INFO] Building bookkeeper-server 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ bookkeeper-server ---
[INFO] 
[INFO] --- apache-rat-plugin:0.7:check (default-cli) @ bookkeeper-server ---
[INFO] Exclude: **/DataFormats.java
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.1:process (default) @ 
bookkeeper-server ---
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 153 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 77 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.9:test (default-test) @ bookkeeper-server ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---
Running org.apache.bookkeeper.replication.AutoRecoveryMainTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.25 sec
Running org.apache.bookkeeper.replication.BookieAutoRecoveryTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 28.87 sec
Running org.apache.bookkeeper.replication.BookieLedgerIndexTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.939 sec
Running org.apache.bookkeeper.replication.AuditorPeriodicCheckTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.446 sec
Running org.apache.bookkeeper.replication.AuditorLedgerCheckerTest
Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.068 sec  
FAILURE!
Running org.apache.bookkeeper.replication.TestLedgerUnderreplicationManager
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.228 sec
Running 

[jira] [Commented] (BOOKKEEPER-638) Two bookies could start at the same time to access bookie data.

2013-10-11 Thread Ivan Kelly (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792615#comment-13792615
 ] 

Ivan Kelly commented on BOOKKEEPER-638:
---

Hmm, ok. The behaviour that would match 4.2 behaviour is to block until 
started, but I guess failing fast is better.

+1 on the patch. Pushing in.

 Two bookies could start at the same time to access bookie data.
 ---

 Key: BOOKKEEPER-638
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-638
 Project: Bookkeeper
  Issue Type: Bug
  Components: bookkeeper-server
Affects Versions: 4.3.0
Reporter: Sijie Guo
Assignee: Sijie Guo
Priority: Blocker
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-638.diff


 this issue is introduced in providing netty server for bookie.
 in BOOKKEEPER-294, we agreed on the start sequence of bookie:
 1) bind bookie port first (to avoid two processes running at the same host).
 2) start bookie (e.g initialize bookie storage and replaying journals)
 3) start nio server to accept incoming requests.
 but after refactoring for netty server, step 1) is combined to be executed in 
 step 3), so two processes could have chance to run at the same time replaying 
 journals. this is pretty bad.
 we need to change the code to stick on the sequence described above.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Jenkins build is back to normal : bookkeeper-trunk #394

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/bookkeeper-trunk/394/changes



[jira] [Commented] (BOOKKEEPER-638) Two bookies could start at the same time to access bookie data.

2013-10-11 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792676#comment-13792676
 ] 

Hudson commented on BOOKKEEPER-638:
---

SUCCESS: Integrated in bookkeeper-trunk #394 (See 
[https://builds.apache.org/job/bookkeeper-trunk/394/])
BOOKKEEPER-638: Two bookies could start at the same time to access bookie data. 
(sijie via ivank) (ivank: rev 1531302)
* /zookeeper/bookkeeper/trunk/CHANGES.txt
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/proto/BookieNettyServer.java


 Two bookies could start at the same time to access bookie data.
 ---

 Key: BOOKKEEPER-638
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-638
 Project: Bookkeeper
  Issue Type: Bug
  Components: bookkeeper-server
Affects Versions: 4.3.0
Reporter: Sijie Guo
Assignee: Sijie Guo
Priority: Blocker
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-638.diff


 this issue is introduced in providing netty server for bookie.
 in BOOKKEEPER-294, we agreed on the start sequence of bookie:
 1) bind bookie port first (to avoid two processes running at the same host).
 2) start bookie (e.g initialize bookie storage and replaying journals)
 3) start nio server to accept incoming requests.
 but after refactoring for netty server, step 1) is combined to be executed in 
 step 3), so two processes could have chance to run at the same time replaying 
 journals. this is pretty bad.
 we need to change the code to stick on the sequence described above.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (BOOKKEEPER-659) LRU page management in ledger cache.

2013-10-11 Thread Ivan Kelly (JIRA)

 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Kelly updated BOOKKEEPER-659:
--

Attachment: 0001-BOOKKEEPER-659-LRU-page-management-in-ledger-cache.patch

I've rebased onto current trunk. It's failing some test though (output 
attached), with an IllegalStateException

{quote}
2013-10-11 16:52:17,047 - INFO  - [New I/O client worker 
#36-3:PerChannelBookieClient$1@135] - Successfully connected to bookie: [id: 
0x08c1e4d5, /10.78.36.43:51868 =gt; /10.78.36.43:15004]
2013-10-11 16:52:17,047 - INFO  - [New I/O server worker 
#7-4:IndexInMemPageMgr@449] - Could not grab a clean page for ledger 4, entry 
0, force flushing dirty ledgers.
2013-10-11 16:52:17,054 - ERROR - [New I/O server worker 
#9-4:BookieRequestHandler@82] - Unhandled exception occurred in I/O thread or 
handler
java.lang.IllegalStateException: Use count has gone below 0
at 
org.apache.bookkeeper.bookie.LedgerEntryPage.releasePage(LedgerEntryPage.java:86)
at 
org.apache.bookkeeper.bookie.IndexInMemPageMgr.grabLedgerEntryPage(IndexInMemPageMgr.java:406)
at 
org.apache.bookkeeper.bookie.IndexInMemPageMgr.getEntryOffset(IndexInMemPageMgr.java:526)
at 
org.apache.bookkeeper.bookie.LedgerCacheImpl.getEntryOffset(LedgerCacheImpl.java:74)
at 
org.apache.bookkeeper.bookie.InterleavedLedgerStorage.getEntry(InterleavedLedgerStorage.java:158)
at 
org.apache.bookkeeper.bookie.LedgerDescriptorImpl.readEntry(LedgerDescriptorImpl.java:85)
at org.apache.bookkeeper.bookie.Bookie.readEntry(Bookie.java:991)
at 
org.apache.bookkeeper.proto.BookieRequestHandler.handleRead(BookieRequestHandler.java:236)
at 
org.apache.bookkeeper.proto.BookieRequestHandler.messageReceived(BookieRequestHandler.java:121)
at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
at 
org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:76)
at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:302)
at 
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:317)
at 
org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:299)
at 
org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:216)
at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at 
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349)
at 
org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:280)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:200)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
2013-10-11 16:52:17,055 - INFO  - [New I/O server worker 
#9-4:IndexInMemPageMgr@449] - Could not grab a clean page for ledger 4, entry 
0, force flushing dirty ledgers.
{quote}

 LRU page management in ledger cache.
 

 Key: BOOKKEEPER-659
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-659
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 
 0001-BOOKKEEPER-659-LRU-page-management-in-ledger-cache.patch, 
 BOOKKEEPER-659.diff


 better ledger page management.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (BOOKKEEPER-659) LRU page management in ledger cache.

2013-10-11 Thread Ivan Kelly (JIRA)

 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Kelly updated BOOKKEEPER-659:
--

Attachment: 
TEST-org.apache.bookkeeper.replication.AuditorPeriodicCheckTest.xml

 LRU page management in ledger cache.
 

 Key: BOOKKEEPER-659
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-659
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 
 0001-BOOKKEEPER-659-LRU-page-management-in-ledger-cache.patch, 
 BOOKKEEPER-659.diff, 
 TEST-org.apache.bookkeeper.replication.AuditorPeriodicCheckTest.xml


 better ledger page management.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-659) LRU page management in ledger cache.

2013-10-11 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792682#comment-13792682
 ] 

Hadoop QA commented on BOOKKEEPER-659:
--

Testing JIRA BOOKKEEPER-659


Patch 
[TEST-org.apache.bookkeeper.replication.AuditorPeriodicCheckTest.xml|https://issues.apache.org/jira/secure/attachment/12608011/TEST-org.apache.bookkeeper.replication.AuditorPeriodicCheckTest.xml]
 downloaded at Fri Oct 11 15:01:00 UTC 2013



{color:red}-1{color} Patch failed to apply to head of branch



 LRU page management in ledger cache.
 

 Key: BOOKKEEPER-659
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-659
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 
 0001-BOOKKEEPER-659-LRU-page-management-in-ledger-cache.patch, 
 BOOKKEEPER-659.diff, 
 TEST-org.apache.bookkeeper.replication.AuditorPeriodicCheckTest.xml


 better ledger page management.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-657) Journal Improvement

2013-10-11 Thread Sijie Guo (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793231#comment-13793231
 ] 

Sijie Guo commented on BOOKKEEPER-657:
--

+1 for the rebased patch. thanks Ivan. committing.

 Journal Improvement
 ---

 Key: BOOKKEEPER-657
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-657
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-657-Journal-Improvement.patch, 
 BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, 
 BOOKKEEPER-657.patch


 separated force write thread, better group commit strategy on latency and 
 throughput.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (BOOKKEEPER-657) Journal Improvement

2013-10-11 Thread Sijie Guo (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793233#comment-13793233
 ] 

Sijie Guo commented on BOOKKEEPER-657:
--

committed as r1531494. and 1531495 (add missing file).

 Journal Improvement
 ---

 Key: BOOKKEEPER-657
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-657
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-657-Journal-Improvement.patch, 
 BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, 
 BOOKKEEPER-657.patch


 separated force write thread, better group commit strategy on latency and 
 throughput.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


Build failed in Jenkins: bookkeeper-trunk #395

2013-10-11 Thread Apache Jenkins Server
See https://builds.apache.org/job/bookkeeper-trunk/395/changes

Changes:

[sijie] BOOKKEEPER-657: Journal Improvement (Robin Dhamankar via sijie) (add 
missing file)

[sijie] BOOKKEEPER-657: Journal Improvement (Robin Dhamankar via sijie)

--
[...truncated 457 lines...]
[INFO] Compiling 6 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
hedwig-protocol ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/src/test/resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ 
hedwig-protocol ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.9:test (default-test) @ hedwig-protocol ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ hedwig-protocol ---
[INFO] Building jar: 
https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/hedwig-protocol-4.3.0-SNAPSHOT.jar
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:findbugs (findbugs) @ hedwig-protocol ---
[INFO] Fork Value is true
[INFO] Done FindBugs Analysis
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol ---
[INFO] BugInstance size is 0
[INFO] Error size is 0
[INFO] No errors/warnings found
[INFO] 
[INFO] 
[INFO] Building bookkeeper-server 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ bookkeeper-server ---
[INFO] 
[INFO] --- apache-rat-plugin:0.7:check (default-cli) @ bookkeeper-server ---
[INFO] Exclude: **/DataFormats.java
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.1:process (default) @ 
bookkeeper-server ---
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 155 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 78 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.9:test (default-test) @ bookkeeper-server ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---
Running org.apache.bookkeeper.replication.AutoRecoveryMainTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.191 sec
Running org.apache.bookkeeper.replication.BookieAutoRecoveryTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 28.859 sec
Running org.apache.bookkeeper.replication.BookieLedgerIndexTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.986 sec
Running org.apache.bookkeeper.replication.AuditorPeriodicCheckTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.315 sec  
FAILURE!
Running org.apache.bookkeeper.replication.AuditorLedgerCheckerTest
Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 24.285 sec  
FAILURE!
Running org.apache.bookkeeper.replication.TestLedgerUnderreplicationManager
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, 

[jira] [Commented] (BOOKKEEPER-657) Journal Improvement

2013-10-11 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793237#comment-13793237
 ] 

Hudson commented on BOOKKEEPER-657:
---

FAILURE: Integrated in bookkeeper-trunk #395 (See 
[https://builds.apache.org/job/bookkeeper-trunk/395/])
BOOKKEEPER-657: Journal Improvement (Robin Dhamankar via sijie) (add missing 
file) (sijie: rev 1531495)
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/conf
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/conf/TestBKConfiguration.java
BOOKKEEPER-657: Journal Improvement (Robin Dhamankar via sijie) (sijie: rev 
1531494)
* /zookeeper/bookkeeper/trunk/CHANGES.txt
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Bookie.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/BookieThread.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/BufferedChannel.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Journal.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/JournalChannel.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/SyncThread.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/conf/ServerConfiguration.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/DaemonThreadFactory.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/MathUtils.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/BookieInitializationTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/BookieJournalTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/CookieTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/CreateNewLogTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/EntryLogTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/LedgerCacheTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/TestLedgerDirsManager.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/UpgradeTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/replication/TestLedgerUnderreplicationManager.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookKeeperClusterTestCase.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieClientTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/BookieJournalRollingTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/ConcurrentLedgerTest.java
* 
/zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/TestBackwardCompat.java
* 
/zookeeper/bookkeeper/trunk/hedwig-server/src/test/java/org/apache/hedwig/server/persistence/BookKeeperTestBase.java


 Journal Improvement
 ---

 Key: BOOKKEEPER-657
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-657
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Robin Dhamankar
 Fix For: 4.3.0

 Attachments: 0001-BOOKKEEPER-657-Journal-Improvement.patch, 
 BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, BOOKKEEPER-657.patch, 
 BOOKKEEPER-657.patch


 separated force write thread, better group commit strategy on latency and 
 throughput.



--
This message was sent by Atlassian JIRA
(v6.1#6144)