[jira] [Updated] (ZOOKEEPER-2479) Add 'fleTimeTaken' value in LeaderMXBean and FollowerMXBean

[Rakesh R (JIRA)]

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

Rakesh R updated ZOOKEEPER-2479:

Component/s: quorum

> Add 'fleTimeTaken' value in LeaderMXBean and FollowerMXBean
> ---
>
> Key: ZOOKEEPER-2479
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2479
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: quorum
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.4.9, 3.5.3
>
>
> The idea of this jira is to expose {{time taken}} for the leader election via 
> jmx Leader, Follower beans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2479) Add 'fleTimeTaken' value in LeaderMXBean and FollowerMXBean

[Rakesh R (JIRA)]

Rakesh R created ZOOKEEPER-2479:
---

 Summary: Add 'fleTimeTaken' value in LeaderMXBean and 
FollowerMXBean
 Key: ZOOKEEPER-2479
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2479
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 3.4.9, 3.5.3


The idea of this jira is to expose {{time taken}} for the leader election via 
jmx Leader, Follower beans.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ZOOKEEPER-2478) Duplicate 'the' on Zab in words Wiki page

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira resolved ZOOKEEPER-2478.
-
Resolution: Fixed

I've fixed it, thanks for reporting it.

> Duplicate 'the' on Zab in words Wiki page
> -
>
> Key: ZOOKEEPER-2478
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2478
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Richard Shaw
>Assignee: Flavio Junqueira
>Priority: Trivial
>  Labels: documentation
>
> There's a duplicate 'the' on the Zookeeper wiki
> Zab in words
> Phase 1: Establish an epoch
> 4.1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ZOOKEEPER-2478) Duplicate 'the' on Zab in words Wiki page

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira reassigned ZOOKEEPER-2478:
---

Assignee: Flavio Junqueira

> Duplicate 'the' on Zab in words Wiki page
> -
>
> Key: ZOOKEEPER-2478
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2478
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Richard Shaw
>Assignee: Flavio Junqueira
>Priority: Trivial
>  Labels: documentation
>
> There's a duplicate 'the' on the Zookeeper wiki
> Zab in words
> Phase 1: Establish an epoch
> 4.1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Rakesh R (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383577#comment-15383577
 ] 

Rakesh R edited comment on ZOOKEEPER-1045 at 7/19/16 4:55 AM:
--

bq.  I believe we should do similar, if not for security then for consistency.
Agreed. Previously in this jira, [~dbenediktson] has brought up a case where 
all the ZK hosts run with the same Kerberos principal. So now we have two 
cases, need to support both {{_HOST}} based principal name and {{shared}} 
principal name. I'm assuming there won't be any need of supporting mixture of 
both of these like, few quorum servers with "zkquorum/_HOST@" pattern in their 
principal name and few others are having constant name "zkquorum@". 

Following is an idea to support both the cases. Welcome comments.

*Case-1)* {{_HOST}} based principal -> For example, zkquorum/_h...@example.com
zoo.cfg has the following configuration which has the 'host' information. This 
host address {{addr.getCanonicalHostName()}} will be used to replace the 
{{_HOST}} pattern. We will make use of the existing data structure 
{{QuorumCnxManager#view}} map to get the respective server's host name. While 
connecting to the respective server, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern then convert the Kerberos principal name to a valid name by replacing 
the {{_HOST}} part. Myid will be used as the key to get the respective quorum 
server address from the {{#view}}.
{code}
server.0=host1:11222:11223:participant
server.1=host2:11225:11226:participant
server.2=host3:11228:11229:participant 
{code}

*Case-2)* Shared principal -> For example, zkquo...@example.com
While connecting to peer servers, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern, if not then will directly use the value as Kerberos principal name and 
continue with the authentication process.

*Case-3* Mixture of {{_HOST}} based and constant principal
This won't be supported. We will supports only two valid principal names, 
either all servers should have "_HOST" based principal name or all servers 
shares same principal name.

bq. I this this is a great idea, however is it possible to move to another 
jira? 
OK, I will push this separately

bq. It looks like we don't have any tests to verify the authz aspect of the 
change? 
Yes, will include test case for this.


was (Author: rakeshr):
bq.  I believe we should do similar, if not for security then for consistency.
Agreed. Previously in this jira, [~dbenediktson] has brought up a case where 
all the ZK hosts run with the same Kerberos principal. So now we have two 
cases, need to support both {{_HOST}} based principal name and {{shared}} 
principal name. I'm assuming there won't be any need of supporting mixture of 
both of these like, few quorum servers with "zkquorum/_HOST@" pattern in their 
principal name and few others are having constant name "zkquorum@". 

Following is an idea to support both the cases. Welcome comments.

*Case-1)* {{_HOST}} based principal -> For example, zkquorum/_h...@example.com
zoo.cfg has the following configuration which has the 'host' information. This 
host address {{addr.getCanonicalHostName()}} will be used to replace the 
{{_HOST}} pattern. We will make use of the existing data structure 
{{QuorumCnxManager#view}} map to get the respective server's host name. While 
connecting to the respective server, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern then convert the Kerberos principal name to a valid name by replacing 
the {{_HOST}} part. Myid will be used as the key to get the respective quorum 
server address from the {{#view}}.
{code}
server.0=host1:11222:11223:participant
server.1=host2:11225:11226:participant
server.2=host3:11228:11229:participant 
{code}

*Case-2)* Shared principal -> For example, zkquo...@example.com
While connecting to peer servers, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern, if not then will directly use the value as Kerberos principal name and 
continue with the authentication process.

*Case-3* Mixture of {{_HOST}} based and constant principal
ZooKeeper doesn't supports this case. ZooKeeper supports only two valid 
principal names, either all servers should have "_HOST" based principal name or 
all servers shares same principal name.

bq. I this this is a great idea, however is it possible to move to another 
jira? 
OK, I will push this separately

bq. It looks like we don't have any tests to verify the authz aspect of the 
change? 
Yes, will include test case for this.

> Support Quorum Peer mutual authentication via SASL
> --
>
>   

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Rakesh R (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383577#comment-15383577
 ] 

Rakesh R commented on ZOOKEEPER-1045:
-

bq.  I believe we should do similar, if not for security then for consistency.
Agreed. Previously in this jira, [~dbenediktson] has brought up a case where 
all the ZK hosts run with the same Kerberos principal. So now we have two 
cases, need to support both {{_HOST}} based principal name and {{shared}} 
principal name. I'm assuming there won't be any need of supporting mixture of 
both of these like, few quorum servers with "zkquorum/_HOST@" pattern in their 
principal name and few others are having constant name "zkquorum@". 

Following is an idea to support both the cases. Welcome comments.

*Case-1)* {{_HOST}} based principal -> For example, zkquorum/_h...@example.com
zoo.cfg has the following configuration which has the 'host' information. This 
host address {{addr.getCanonicalHostName()}} will be used to replace the 
{{_HOST}} pattern. We will make use of the existing data structure 
{{QuorumCnxManager#view}} map to get the respective server's host name. While 
connecting to the respective server, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern then convert the Kerberos principal name to a valid name by replacing 
the {{_HOST}} part. Myid will be used as the key to get the respective quorum 
server address from the {{#view}}.
{code}
server.0=host1:11222:11223:participant
server.1=host2:11225:11226:participant
server.2=host3:11228:11229:participant 
{code}

*Case-2)* Shared principal -> For example, zkquo...@example.com
While connecting to peer servers, first the quorum learner will check 
{{quorum.auth.kerberos.servicePrincipal}} configuration has {{_HOST}} name 
pattern, if not then will directly use the value as Kerberos principal name and 
continue with the authentication process.

*Case-3* Mixture of {{_HOST}} based and constant principal
ZooKeeper doesn't supports this case. ZooKeeper supports only two valid 
principal names, either all servers should have "_HOST" based principal name or 
all servers shares same principal name.

bq. I this this is a great idea, however is it possible to move to another 
jira? 
OK, I will push this separately

bq. It looks like we don't have any tests to verify the authz aspect of the 
change? 
Yes, will include test case for this.

> Support Quorum Peer mutual authentication via SASL
> --
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Eugene Koontz
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.9, 3.5.3
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, 
> 1045_failing_phunt.tar.gz, ZK-1045-test-case-failure-logs.zip, 
> ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045TestValidationDesign.pdf
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers. 
> This bug, on the other hand, is for authentication among quorum peers. 
> Hopefully much of the work done on SASL integration with Zookeeper for 
> ZOOKEEPER-938 can be used as a foundation for this enhancement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2466) Client skips servers when trying to connect

[Flavio Junqueira (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383563#comment-15383563
 ] 

Flavio Junqueira commented on ZOOKEEPER-2466:
-

[~hanm] as you explained, there is a behavior change since with RO status the 
client won't look for an RW server until the reconfig completes. Say that it 
disconnects from the RO server, though, maybe because the RO server has been 
removed from the configuration. What happens in this case? I'd expect that 
either it looks for another RO server or it waits until the reconfig completes, 
although the former is more aligned with the behavior we describe in the 
documentation.

Also, I was thinking if we need a test case for this. We found out about this 
problem through a test case, but apparently it doesn't always fails. It might 
be worth checking that the order of servers is as expected. 

> Client skips servers when trying to connect
> ---
>
> Key: ZOOKEEPER-2466
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2466
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Reporter: Flavio Junqueira
>Assignee: Michael Han
>Priority: Critical
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2466.patch
>
>
> I've been looking at {{Zookeeper_simpleSystem::testFirstServerDown}} and I 
> observed the following behavior. The list of servers to connect contains two 
> servers, let's call them S1 and S2. The client never connects, but the odd 
> bit is the sequence of servers that the client tries to connect to:
> {noformat}
> S1
> S2
> S1
> S1
> S1
> 
> {noformat}
> It intrigued me that S2 is only tried once and never again. Checking the 
> code, here is what happens. Initially, {{zh->reconfig}} is 1, so in 
> {{zoo_cycle_next_server}} we return an address from 
> {{get_next_server_in_reconfig}}, which is taken from {{zh->addrs_new}} in 
> this test case. The attempt to connect fails, and {{handle_error}} is invoked 
> in the error handling path. {{handle_error}} actually invokes 
> {{addrvec_next}} which changes the address pointer to the next server on the 
> list.
> After two attempts, it decides that it has tried all servers in 
> {{zoo_cycle_next_server}} and sets {{zh->reconfig}} to zero. Once 
> {{zh->reconfig == 0}}, we have that each call to {{zoo_cycle_next_server}} 
> moves the address pointer to the next server in {{zh->addrs}}. But, given 
> that {{handle_error}} also moves the pointer to the next server, we end up 
> moving the pointer ahead twice upon every failed attempt to connect, which is 
> wrong.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ZOOKEEPER-2014) Only admin should be allowed to reconfig a cluster

[Michael Han (JIRA)]

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

Michael Han reassigned ZOOKEEPER-2014:
--

Assignee: Michael Han  (was: Raul Gutierrez Segales)

> Only admin should be allowed to reconfig a cluster
> --
>
> Key: ZOOKEEPER-2014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Michael Han
>Priority: Blocker
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We 
> should, at the very least, ensure that only the Admin can reconfigure a 
> cluster. Perhaps restricting access to /zookeeper/config as well, though this 
> is debatable. Surely one could ensure Admin only access via an ACL, but that 
> would leave everyone who doesn't use ACLs unprotected. We could also force a 
> default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run 
> with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure 
> if everyone does, or how would it work with other authentication providers). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2478) Duplicate 'the' on Zab in words Wiki page

[Richard Shaw (JIRA)]

Richard Shaw created ZOOKEEPER-2478:
---

 Summary: Duplicate 'the' on Zab in words Wiki page
 Key: ZOOKEEPER-2478
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2478
 Project: ZooKeeper
  Issue Type: Bug
  Components: documentation
Reporter: Richard Shaw
Priority: Trivial


There's a duplicate 'the' on the Zookeeper wiki
Zab in words

Phase 1: Establish an epoch
4.1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

ZooKeeper-trunk - Build # 2999 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk/2999/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 403242 lines...]
[junit] at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:479)
[junit] at 
org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromTaskLoop(AbstractNioWorker.java:151)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioChannel$WriteTask.run(AbstractNioChannel.java:315)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89)
[junit] at 
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178)
[junit] at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-07-19 00:23:29,885 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port19545,name1=Connections,name2=127.0.0.1,name3=0x1015a298774]
[junit] 2016-07-19 00:23:29,985 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1015a298774 closed
[junit] 2016-07-19 00:23:29,985 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 164363
[junit] 2016-07-19 00:23:29,985 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1015a298774
[junit] 2016-07-19 00:23:29,985 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1641
[junit] 2016-07-19 00:23:29,986 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-07-19 00:23:29,986 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-07-19 00:23:29,986 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-07-19 00:23:29,987 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:19545
[junit] 2016-07-19 00:23:29,995 [myid:] - INFO  [main:ZooKeeperServer@498] 
- shutting down
[junit] 2016-07-19 00:23:29,995 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-07-19 00:23:29,996 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-07-19 00:23:29,996 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-07-19 00:23:29,997 [myid:] - INFO  [ProcessThread(sid:0 
cport:19545)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-07-19 00:23:29,997 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-07-19 00:23:29,997 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-07-19 00:23:29,998 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port19545,name1=InMemoryDataTree]
[junit] 2016-07-19 00:23:29,998 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port19545]
[junit] 2016-07-19 00:23:29,998 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 19545
[junit] 2016-07-19 00:23:29,999 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-07-19 00:23:30,005 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 4817 at start it was 4817
[junit] 2016-07-19 00:23:30,005 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-07-19 00:23:30,005 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
518.773 sec, Thread: 4, Class: org.apache.zookeeper.test.NioNettySuiteTest

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build.xml:1322: The 
following error occurred while executing this line:

Failed: ZOOKEEPER-2477 PreCommit Build #3277

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3277/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 401551 lines...]
 [exec] 
 [exec] +0 tests included.  The patch appears to be a documentation 
patch that doesn't require 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 2.0.3) 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/3277//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3277//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3277//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] 76c7d34862c171be780ebce2ecec8b378899f221 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:1605:
 exec returned: 1

Total time: 14 minutes 49 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Compressed 552.45 KB of artifacts by 46.3% relative to #3273
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2477
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
4 tests failed.
FAILED:  
org.apache.zookeeper.RemoveWatchesTest.testManyWatchersWhenNoConnection[1]

Error Message:
Didn't succeeds removeWatch operation

Stack Trace:
junit.framework.AssertionFailedError: Didn't succeeds removeWatch operation
at 
org.apache.zookeeper.RemoveWatchesTest.removeWatches(RemoveWatchesTest.java:97)
at 
org.apache.zookeeper.RemoveWatchesTest.testManyWatchersWhenNoConnection(RemoveWatchesTest.java:692)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.zookeeper.test.FLEZeroWeightTest.testZeroWeightQuorum

Error Message:
Threads didn't join

Stack Trace:
junit.framework.AssertionFailedError: Threads didn't join
at 
org.apache.zookeeper.test.FLEZeroWeightTest.testZeroWeightQuorum(FLEZeroWeightTest.java:167)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)


FAILED:  org.apache.zookeeper.test.FourLetterWordsTest.testFourLetterWords

Error Message:
Exception while executing four letter word: dump

Stack Trace:
java.io.IOException: Exception while executing four letter word: dump
at 

[jira] [Commented] (ZOOKEEPER-2477) documentation should refer to Java cli shell and not C cli shell

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383309#comment-15383309
 ] 

Hadoop QA commented on ZOOKEEPER-2477:
--

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

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

+0 tests included.  The patch appears to be a documentation patch that 
doesn't require tests.

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

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

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

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

-1 core tests.  The patch failed core unit tests.

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

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

This message is automatically generated.

> documentation should refer to Java cli shell and not C cli shell
> 
>
> Key: ZOOKEEPER-2477
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Patrick Hunt
>Assignee: Abraham Fine
>  Labels: newbie
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2477-br3.4.patch, ZOOKEEPER-2477.patch
>
>
> The documentation tends to refer to the c cli shell when citing examples of 
> how to interact with ZK, rather than using the Java cli shell. Given the Java 
> cli is much better maintained and more featureful the docs should refer to 
> that instead. Also the c cli was originally meant to be a sample/example of c 
> client usage rather than a true cli tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-1441) Some test cases are failing because Port bind issue.

[Michael Han (JIRA)]

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

Michael Han updated ZOOKEEPER-1441:
---
Labels: flaky flaky-test  (was: )

> Some test cases are failing because Port bind issue.
> 
>
> Key: ZOOKEEPER-1441
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1441
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: kavita sharma
>Assignee: Michael Han
>  Labels: flaky, flaky-test
>
> very frequently testcases are failing because of :
> java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind(Native Method)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
>   at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:111)
>   at 
> org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:112)
>   at 
> org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:514)
>   at 
> org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:156)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:103)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:67)
> may be because of Port Assignment so please give me some suggestions if 
> someone is also facing same problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-1441) Some test cases are failing because Port bind issue.

[Michael Han (JIRA)]

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

Michael Han updated ZOOKEEPER-1441:
---
Component/s: server

> Some test cases are failing because Port bind issue.
> 
>
> Key: ZOOKEEPER-1441
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1441
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: kavita sharma
>Assignee: Michael Han
>  Labels: flaky, flaky-test
>
> very frequently testcases are failing because of :
> java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind(Native Method)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
>   at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:111)
>   at 
> org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:112)
>   at 
> org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:514)
>   at 
> org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:156)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:103)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:67)
> may be because of Port Assignment so please give me some suggestions if 
> someone is also facing same problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2477) documentation should refer to Java cli shell and not C cli shell

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2477:

Attachment: ZOOKEEPER-2477.patch

> documentation should refer to Java cli shell and not C cli shell
> 
>
> Key: ZOOKEEPER-2477
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Patrick Hunt
>Assignee: Abraham Fine
>  Labels: newbie
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2477-br3.4.patch, ZOOKEEPER-2477.patch
>
>
> The documentation tends to refer to the c cli shell when citing examples of 
> how to interact with ZK, rather than using the Java cli shell. Given the Java 
> cli is much better maintained and more featureful the docs should refer to 
> that instead. Also the c cli was originally meant to be a sample/example of c 
> client usage rather than a true cli tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2477) documentation should refer to Java cli shell and not C cli shell

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2477:

Attachment: (was: ZOOKEEPER-2477.patch)

> documentation should refer to Java cli shell and not C cli shell
> 
>
> Key: ZOOKEEPER-2477
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Patrick Hunt
>Assignee: Abraham Fine
>  Labels: newbie
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2477-br3.4.patch
>
>
> The documentation tends to refer to the c cli shell when citing examples of 
> how to interact with ZK, rather than using the Java cli shell. Given the Java 
> cli is much better maintained and more featureful the docs should refer to 
> that instead. Also the c cli was originally meant to be a sample/example of c 
> client usage rather than a true cli tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383145#comment-15383145
 ] 

Patrick Hunt commented on ZOOKEEPER-1045:
-

bq. the current patch is supporting only single (shared) Kerberos principal

I don't think we want to make this simplification. I asked around for the other 
components (e.g. hdfs/hbase) and they assign a single cred to each of the 
services - user/host@realm. Their authz check will verify the user and realm, 
but of course the hosts differ across servers/processes. In asking why they do 
this rather than the shared approach they said it was due to ease of management 
- in our case the servers likely already have user/host@realm, and two if a 
particular host/credential is compromised it's much easier to change. I believe 
we should do similar, if not for security then for consistency.

bq. Exposed fleTimeTaken

I this this is a great idea, however is it possible to move to another jira? It 
would be easy to fasttrack that into releases. My concern is that this patch is 
already pretty big/complicated and I'd really like to focus on the auth pieces. 
Again, great idea to add this to the system though.

bq. new tests

It looks like we don't have any tests to verify the authz aspect of the change? 
The two new tests, their comments seem to say they same thing and afaict 
doesn't verify authz functionality?



> Support Quorum Peer mutual authentication via SASL
> --
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Eugene Koontz
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.9, 3.5.3
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, 
> 1045_failing_phunt.tar.gz, ZK-1045-test-case-failure-logs.zip, 
> ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045TestValidationDesign.pdf
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers. 
> This bug, on the other hand, is for authentication among quorum peers. 
> Hopefully much of the work done on SASL integration with Zookeeper for 
> ZOOKEEPER-938 can be used as a foundation for this enhancement.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2477) documentation should refer to Java cli shell and not C cli shell

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2477:

Attachment: ZOOKEEPER-2477-br3.4.patch

> documentation should refer to Java cli shell and not C cli shell
> 
>
> Key: ZOOKEEPER-2477
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Patrick Hunt
>Assignee: Abraham Fine
>  Labels: newbie
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2477-br3.4.patch, ZOOKEEPER-2477.patch
>
>
> The documentation tends to refer to the c cli shell when citing examples of 
> how to interact with ZK, rather than using the Java cli shell. Given the Java 
> cli is much better maintained and more featureful the docs should refer to 
> that instead. Also the c cli was originally meant to be a sample/example of c 
> client usage rather than a true cli tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ZOOKEEPER-1441) Some test cases are failing because Port bind issue.

[Michael Han (JIRA)]

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

Michael Han reassigned ZOOKEEPER-1441:
--

Assignee: Michael Han

> Some test cases are failing because Port bind issue.
> 
>
> Key: ZOOKEEPER-1441
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1441
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: kavita sharma
>Assignee: Michael Han
>
> very frequently testcases are failing because of :
> java.net.BindException: Address already in use
>   at sun.nio.ch.Net.bind(Native Method)
>   at 
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
>   at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
>   at 
> org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:111)
>   at 
> org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:112)
>   at 
> org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:514)
>   at 
> org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:156)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:103)
>   at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:67)
> may be because of Port Assignment so please give me some suggestions if 
> someone is also facing same problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: ZooKeeper 3.4.9 release discussion

[Patrick Hunt]

On Sat, Jul 9, 2016 at 10:26 AM, Rakesh Radhakrishnan
 wrote:
>
> >ZK-1045 is a major change and I suggest we give time for folks to try
> it out before cutting a release candidate. Ideally, we check it in and give
> a few weeks until we cut a release candidate.
>
> Agreed, will try to push ZK-1045 in asap. Michael and myself is working
> closely to finish the following set of open points. Hopefully by next week
> we will be able to complete the identified tasks, then will post updated
> patch and test report. I would appreciate review
> comments/questions/feedback from others.
>

I am taking another pass at this next.

> Pending tasks:-
> 1) support authorization in sasl.
> 2) few minor log improvements are open.
> 3) system testing and preparing report.
> 4) feature document with latest changes.
>
>
> >The other one, ZK-2383, needs work.
>
> Here, I'm planning to revert ZOOKEEPER-2026 committed code and makes this
> issue open for discussion/fix. Does it sound good?
>

Given 2026 is already shipping I would be concerned about reverting it
at this point. Why wouldn't we just fix the remaining issue(s)?

Patrick

> Thanks,
> Rakesh
>
> On Thu, Jul 7, 2016 at 6:51 PM, Flavio Junqueira  wrote:
>
> > Thanks for bootstrapping the release process for 3.4.9. ZK-1045 is a major
> > change and I suggest we give time for folks to try it out before cutting a
> > release candidate. Ideally, we check it in and give a few weeks until we
> > cut a release candidate.
> >
> > One of the blockers, ZK-2314 has only one remaining task which is to
> > document missing SASL properties, so that should be easy. The other one,
> > ZK-2383, needs work.
> >
> > Folks should check the remaining issues to determine if there is any other
> > blocker that we missed in that list.
> >
> > -Flavio
> >
> > > On 07 Jul 2016, at 05:12, Rakesh Radhakrishnan 
> > wrote:
> > >
> > > Hi All,
> > >
> > > I am interested in going through the release process as the RM.
> > >
> > > I could see total 23 issues marked for 3.4.9 release as of now, which
> > > includes 2 blockers, 6 critical, 12 major and 3 minor issues. I count 15
> > > issues fixed/committed already for 3.4.9 which includes 6 blockers and 2
> > > critical(security related) issues. I think it is a good time to initiate
> > > the discussion of 3.4.9 release processes.
> > >
> > > Please find the open issues here, https://goo.gl/SEliwm
> > >
> > > Currently, I'm focusing on ZOOKEEPER-1045 sasl feature which I think is
> > > much appreciated/awaited feature and I'd like to include this if everyone
> > > agrees. Appreciate help in reviewing/testing the patch and making it
> > stable
> > > for release. Also, please feel free to push your favorite issues ahead of
> > > 3.4.9 release.
> > >
> > > I hope we should be able to close all blockers and critical issues in a
> > > month. Kindly requesting everyone to look at the issues marked for 3.4.9
> > > and push these asap or can be pushed out to 3.4.10. I will focus my code
> > > review time on these.
> > >
> > > Please let me know your thoughts on the plan.
> > >
> > > Thanks,
> > > Rakesh
> >
> >

ZooKeeper-trunk-openjdk7 - Build # 1096 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/1096/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 396282 lines...]
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-07-18 20:26:00,879 [myid:127.0.0.1:14159] - INFO  
[main-SendThread(127.0.0.1:14159):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:14159. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-07-18 20:26:00,879 [myid:127.0.0.1:14159] - INFO  
[main-SendThread(127.0.0.1:14159):ClientCnxn$SendThread@948] - Socket 
connection established, initiating session, client: /127.0.0.1:37994, server: 
127.0.0.1/127.0.0.1:14159
[junit] 2016-07-18 20:26:00,880 [myid:] - INFO  [New I/O worker 
#1811:ZooKeeperServer@969] - Client attempting to renew session 
0x102b7dafac5 at /127.0.0.1:37994
[junit] 2016-07-18 20:26:00,880 [myid:] - INFO  [New I/O worker 
#1811:ZooKeeperServer@678] - Established session 0x102b7dafac5 with 
negotiated timeout 6000 for client /127.0.0.1:37994
[junit] 2016-07-18 20:26:00,881 [myid:127.0.0.1:14159] - INFO  
[main-SendThread(127.0.0.1:14159):ClientCnxn$SendThread@1381] - Session 
establishment complete on server 127.0.0.1/127.0.0.1:14159, sessionid = 
0x102b7dafac5, negotiated timeout = 6000
[junit] 2016-07-18 20:26:00,883 [myid:] - INFO  
[SyncThread:0:FileTxnLog@204] - Creating new log file: log.7
[junit] 2016-07-18 20:26:00,910 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@158] - SessionTrackerImpl exited loop!
[junit] 2016-07-18 20:26:01,072 [myid:127.0.0.1:14042] - INFO  
[main-SendThread(127.0.0.1:14042):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:14042. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-07-18 20:26:01,073 [myid:127.0.0.1:14042] - WARN  
[main-SendThread(127.0.0.1:14042):ClientCnxn$SendThread@1235] - Session 
0x302b7d7ed09 for server 127.0.0.1/127.0.0.1:14042, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-07-18 20:26:01,891 [myid:] - INFO  [ProcessThread(sid:0 
cport:14159)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x102b7dafac5
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port14159,name1=Connections,name2=127.0.0.1,name3=0x102b7dafac5]
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x102b7dafac5 closed
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x102b7dafac5
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 72602
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 465
[junit] 2016-07-18 20:26:01,894 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-07-18 20:26:01,895 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-07-18 20:26:01,895 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-07-18 20:26:01,895 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:14159
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  [main:ZooKeeperServer@498] 
- shutting down
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  [ProcessThread(sid:0 
cport:14159)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-07-18 20:26:01,897 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-07-18 20:26:01,898 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 

Failed: ZOOKEEPER-2152 PreCommit Build #3276

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2152
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3276/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 405307 lines...]
 [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 2.0.3) 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/3276//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3276//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3276//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] 8763ecf0e5193e8bb59be603ac7a1da42c958bbb 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:1605:
 exec returned: 1

Total time: 19 minutes 23 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Compressed 552.45 KB of artifacts by 46.3% relative to #3273
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2152
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
7 tests failed.
FAILED:  
org.apache.zookeeper.server.ZxidRolloverTest.testRolloverThenFollowerRestart

Error Message:
null

Stack Trace:
java.lang.NullPointerException
at 
org.apache.zookeeper.server.ZxidRolloverTest.tearDown(ZxidRolloverTest.java:217)


FAILED:  org.apache.zookeeper.test.LETest.testLE

Error Message:
Threads didn't join

Stack Trace:
junit.framework.AssertionFailedError: Threads didn't join
at org.apache.zookeeper.test.LETest.testLE(LETest.java:123)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)


FAILED:  
org.apache.zookeeper.test.LoadFromLogTest.testRestoreWithTransactionErrors

Error Message:
KeeperErrorCode = ConnectionLoss for /invaliddir/test-

Stack Trace:
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = 
ConnectionLoss for /invaliddir/test-
at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:1412)
at 
org.apache.zookeeper.test.LoadFromLogTest.testRestoreWithTransactionErrors(LoadFromLogTest.java:452)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)


FAILED:  

[jira] [Commented] (ZOOKEEPER-2152) Intermittent failure in TestReconfig.cc

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382956#comment-15382956
 ] 

Hadoop QA commented on ZOOKEEPER-2152:
--

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

+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 2.0.3) 
warnings.

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

-1 core tests.  The patch failed core unit tests.

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

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

This message is automatically generated.

> Intermittent failure in TestReconfig.cc
> ---
>
> Key: ZOOKEEPER-2152
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2152
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client
>Reporter: Michi Mutsuzaki
>Assignee: Michael Han
>  Labels: reconfiguration
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2152.patch, ZOOKEEPER-2152.patch
>
>
> I'm seeing this failure in the c client test once in a while:
> {noformat}
> [exec] 
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/tests/TestReconfig.cc:474:
>  Assertion: assertion failed [Expression: found != string::npos, 
> 10.10.10.4:2004 not in newComing list]
> {noformat}
> https://builds.apache.org/job/ZooKeeper-trunk/2640/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2152) Intermittent failure in TestReconfig.cc

[Michael Han (JIRA)]

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

Michael Han updated ZOOKEEPER-2152:
---
Attachment: ZOOKEEPER-2152.patch

Generalize the flag by renaming it :) 
After reviewing the code path I think the previous patch is general enough to 
capture the case of having a sticky server, it is just the naming is bad. The 
flag is renamed and comments updated to reflect it's useful for other cases 
(not just reconfig) as well.

> Intermittent failure in TestReconfig.cc
> ---
>
> Key: ZOOKEEPER-2152
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2152
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client
>Reporter: Michi Mutsuzaki
>Assignee: Michael Han
>  Labels: reconfiguration
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2152.patch, ZOOKEEPER-2152.patch
>
>
> I'm seeing this failure in the c client test once in a while:
> {noformat}
> [exec] 
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/tests/TestReconfig.cc:474:
>  Assertion: assertion failed [Expression: found != string::npos, 
> 10.10.10.4:2004 not in newComing list]
> {noformat}
> https://builds.apache.org/job/ZooKeeper-trunk/2640/console



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2477) documentation should refer to Java cli shell and not C cli shell

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2477:

Attachment: ZOOKEEPER-2477.patch

> documentation should refer to Java cli shell and not C cli shell
> 
>
> Key: ZOOKEEPER-2477
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2477
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Patrick Hunt
>Assignee: Abraham Fine
>  Labels: newbie
> Fix For: 3.4.9, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2477.patch
>
>
> The documentation tends to refer to the c cli shell when citing examples of 
> how to interact with ZK, rather than using the Java cli shell. Given the Java 
> cli is much better maintained and more featureful the docs should refer to 
> that instead. Also the c cli was originally meant to be a sample/example of c 
> client usage rather than a true cli tool.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Backporting ZOOKEEPER-2120 (SSL support) to 3.4.8

[Rakesh Radhakrishnan]

>>>Instead I'd recommend we get PMC approval to do a trial run with a single
>>>branch to start. If that's successful we can consider making it more
>>>formalized.

Makes sense to me.

>>> Before we do anything someone should spend some time looking at
>>> what folks like Hadoop are doing (the process).

I'm adding few details which I observed in the Hadoop project. Perhaps,
Chris can correct/edit more about this.

1) PMC proposes for a feature branch in JIRA, then will decide for a
feature branch on any specific branch or trunk. In Hadoop, afaik most of
the features branched out from trunk. But I think if needed the new branch
can be created from a specific branch.
2) In git, creates a new branch named with JIRA name. (For simplicity
please assume feature branch is created from trunk).
3) There is a branch committer option, will allow new guys as branch
committer only for that branch scope.
4) Periodically merge the trunk changes to the feature branch in order to
keep changes minimal when compared to the trunk.
5) All jira sub tasks committed to this feature branch.
6) Hadoop project has done changes to trigger the pre-commit build on that
branch code and get the QA report. For example, upload a patch by appending
the branch name to the patch name. Assume feature jira name is
ZOOKEEPER-2125, then will create a branch called ZOOKEEPER-2125. Again
assume, my jira sub-task is ZOOKEEPER-3000, now will attach the patch named
"ZOOKEEPER-3000-ZOOKEEPER-2125.patch", then Jenkins will pick up this patch
and run against the branch code.
7) When branch maintainer feels, its ready for merge, they will call for
vote. It requires 3 PMC votes for merging the branch to trunk.

Regards,
Rakesh

On Mon, Jul 18, 2016 at 10:55 PM, Patrick Hunt  wrote:

> Changing the bylaws is pretty significant, and would require a vote by the
> PMC.
>
> Instead I'd recommend we get PMC approval to do a trial run with a single
> branch to start. If that's successful we can consider making it more
> formalized. Before we do anything someone should spend some time looking at
> what folks like Hadoop are doing (the process).
>
> Patrick
>
> On Mon, Jul 18, 2016 at 10:16 AM, Rakesh Radhakrishnan  >
> wrote:
>
> > +1(non-binding). Its an interesting idea. I also feel, this would make
> the
> > feature development more easy and can attract more users/contributors.
> >
> > If everyone agrees to this, we could update the project bylaws including
> > the (1)role & responsibility of feature branch committers, (2)merging
> back
> > the feature branch changes to the mainstream (3)branch committer removal
> > etc.
> >
> >
> > Rakesh
> >
> >
> >
> > On Mon, Jul 18, 2016 at 9:51 PM, Flavio Junqueira 
> wrote:
> >
> > > That's a great idea, I'm +1.
> > >
> > > -Flavio
> > >
> > > > On 11 Jul 2016, at 21:13, Patrick Hunt  wrote:
> > > >
> > > > I'd like to recommend that we consider a special 3.4 branch for this.
> > > > (sorry I'm late to the party but I was on vacation till today, just
> > > back).
> > > >
> > > > We could create a 3.4+ssl branch, or something like that, and give
> > > special
> > > > permissions for non-committers to commit to the branch. People that
> are
> > > > interested in this feature but not committers. Once the folks working
> > on
> > > > this are satisfied the PMC could do a special "3.4.9+ssl" release
> > > artifact
> > > > (say just a tarball), separate from the 3.4.x line, for folks that
> are
> > > > interested to use it. This would require minimal oversight by the
> > > > committers. I believe other components are doing this, typically for
> > > > feature development before being merged back in, but it would enable
> > > > interested parties to get access to ssl prior to 3.5 becoming stable.
> > It
> > > > would also benefit 3.5 in the sense that anything we learn on that
> > branch
> > > > would be merged into the trunk - fixes say.
> > > >
> > > > Patrick
> > > >
> > > > On Tue, Jul 5, 2016 at 11:45 AM, Luciano Afranllie <
> > > listas.luaf...@gmail.com
> > > >> wrote:
> > > >
> > > >> Quick question, ZK-2125 depends on
> > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2069 and
> > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2072?
> > > >>
> > > >> It seems to be given the description of ZK-2063...
> > > >>
> > > >> Regards
> > > >> Luciano
> > > >>
> > > >>
> > > >> On Fri, Jul 1, 2016 at 12:20 PM, Flavio Junqueira 
> > > wrote:
> > > >>
> > > >>> I think you're talking about porting the patch of ZK-2125. I
> haven't
> > > >>> really assessed how much work it would be to backport it, but it is
> > > >>> possibly not hard.
> > > >>>
> > > >>> -Flavio
> > > >>>
> > >  On 01 Jul 2016, at 15:54, Luciano Afranllie <
> > listas.luaf...@gmail.com
> > > >
> > > >>> wrote:
> > > 
> > >  Thanks Flavio
> > > 
> > >  What about back porting in our own private fork while we wait for
> > the
> > > >>> 3.5?
> 

Re: Backporting ZOOKEEPER-2120 (SSL support) to 3.4.8

[Patrick Hunt]

Changing the bylaws is pretty significant, and would require a vote by the
PMC.

Instead I'd recommend we get PMC approval to do a trial run with a single
branch to start. If that's successful we can consider making it more
formalized. Before we do anything someone should spend some time looking at
what folks like Hadoop are doing (the process).

Patrick

On Mon, Jul 18, 2016 at 10:16 AM, Rakesh Radhakrishnan 
wrote:

> +1(non-binding). Its an interesting idea. I also feel, this would make the
> feature development more easy and can attract more users/contributors.
>
> If everyone agrees to this, we could update the project bylaws including
> the (1)role & responsibility of feature branch committers, (2)merging back
> the feature branch changes to the mainstream (3)branch committer removal
> etc.
>
>
> Rakesh
>
>
>
> On Mon, Jul 18, 2016 at 9:51 PM, Flavio Junqueira  wrote:
>
> > That's a great idea, I'm +1.
> >
> > -Flavio
> >
> > > On 11 Jul 2016, at 21:13, Patrick Hunt  wrote:
> > >
> > > I'd like to recommend that we consider a special 3.4 branch for this.
> > > (sorry I'm late to the party but I was on vacation till today, just
> > back).
> > >
> > > We could create a 3.4+ssl branch, or something like that, and give
> > special
> > > permissions for non-committers to commit to the branch. People that are
> > > interested in this feature but not committers. Once the folks working
> on
> > > this are satisfied the PMC could do a special "3.4.9+ssl" release
> > artifact
> > > (say just a tarball), separate from the 3.4.x line, for folks that are
> > > interested to use it. This would require minimal oversight by the
> > > committers. I believe other components are doing this, typically for
> > > feature development before being merged back in, but it would enable
> > > interested parties to get access to ssl prior to 3.5 becoming stable.
> It
> > > would also benefit 3.5 in the sense that anything we learn on that
> branch
> > > would be merged into the trunk - fixes say.
> > >
> > > Patrick
> > >
> > > On Tue, Jul 5, 2016 at 11:45 AM, Luciano Afranllie <
> > listas.luaf...@gmail.com
> > >> wrote:
> > >
> > >> Quick question, ZK-2125 depends on
> > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2069 and
> > >> https://issues.apache.org/jira/browse/ZOOKEEPER-2072?
> > >>
> > >> It seems to be given the description of ZK-2063...
> > >>
> > >> Regards
> > >> Luciano
> > >>
> > >>
> > >> On Fri, Jul 1, 2016 at 12:20 PM, Flavio Junqueira 
> > wrote:
> > >>
> > >>> I think you're talking about porting the patch of ZK-2125. I haven't
> > >>> really assessed how much work it would be to backport it, but it is
> > >>> possibly not hard.
> > >>>
> > >>> -Flavio
> > >>>
> >  On 01 Jul 2016, at 15:54, Luciano Afranllie <
> listas.luaf...@gmail.com
> > >
> > >>> wrote:
> > 
> >  Thanks Flavio
> > 
> >  What about back porting in our own private fork while we wait for
> the
> > >>> 3.5?
> >  I would like your help understanding how easy/difficult this may be.
> > 
> >  Regards
> >  Luciano
> > 
> >  On Fri, Jul 1, 2016 at 9:23 AM, Flavio Junqueira 
> > >> wrote:
> > 
> > > Hi Luciano,
> > >
> > > The 3.4 branch is stable and we are only releasing bug fixes at
> this
> > > point, so it is currently not an option to back port.
> > >
> > > We are all pretty eager to see the 3.5 branch stable, and we are in
> > >> the
> > > process of voting the release candidate for 3.5.2, but that's still
> > >>> tagged
> > > as alpha. We don't have a current plan for 3.5.3 yet, but I believe
> > no
> > >>> one
> > > here wants to wait too long have it out. I suspect that it won't be
> > >>> before
> > > 3 months from now given the pace that we have been releasing,
> though.
> > >
> > > -Flavio
> > >
> > >
> > >> On 01 Jul 2016, at 13:07, Luciano Afranllie <
> > >> listas.luaf...@gmail.com>
> > > wrote:
> > >>
> > >> Hi there
> > >>
> > >> We are in the need to have SSL support in Zookeeper in order for
> our
> > >> solution to be FIPS complaint.
> > >>
> > >> Of course one option is to wait for 3.5 to be released but given
> we
> > >>> are a
> > >> little bit time constrained we want to consider an alternative of
> > >> backporting SSL support from 3.5 to 3.4 (we are using 3.4.8)
> > >>
> > >> Do you think this is doable? Can you please tell me the impact of
> > >> doing
> > >> this and if you think it is a viable alternative? We have
> experience
> > >>> with
> > >> Java but not with ZK at development level.
> > >>
> > >> Of, course if you have a rough estimate about when ZK 3.5 may be
> > >>> released
> > >> that may help in our decision too.
> > >>
> > >> Regards
> > >> Luciano
> > >
> > >
> > >>>
> > >>>
> > >>
> >
> >
>

Failed: ZOOKEEPER-2466 PreCommit Build #3275

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2466
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3275/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 397575 lines...]
 [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 2.0.3) 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/3275//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3275//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3275//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] 34c100929b57266d52e3538783bf0c34862acf9d 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:1605:
 exec returned: 1

Total time: 23 minutes 20 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2466
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



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

[jira] [Commented] (ZOOKEEPER-2466) Client skips servers when trying to connect

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15382656#comment-15382656
 ] 

Hadoop QA commented on ZOOKEEPER-2466:
--

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

+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 2.0.3) 
warnings.

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

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

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

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

This message is automatically generated.

> Client skips servers when trying to connect
> ---
>
> Key: ZOOKEEPER-2466
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2466
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Reporter: Flavio Junqueira
>Assignee: Michael Han
>Priority: Critical
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2466.patch
>
>
> I've been looking at {{Zookeeper_simpleSystem::testFirstServerDown}} and I 
> observed the following behavior. The list of servers to connect contains two 
> servers, let's call them S1 and S2. The client never connects, but the odd 
> bit is the sequence of servers that the client tries to connect to:
> {noformat}
> S1
> S2
> S1
> S1
> S1
> 
> {noformat}
> It intrigued me that S2 is only tried once and never again. Checking the 
> code, here is what happens. Initially, {{zh->reconfig}} is 1, so in 
> {{zoo_cycle_next_server}} we return an address from 
> {{get_next_server_in_reconfig}}, which is taken from {{zh->addrs_new}} in 
> this test case. The attempt to connect fails, and {{handle_error}} is invoked 
> in the error handling path. {{handle_error}} actually invokes 
> {{addrvec_next}} which changes the address pointer to the next server on the 
> list.
> After two attempts, it decides that it has tried all servers in 
> {{zoo_cycle_next_server}} and sets {{zh->reconfig}} to zero. Once 
> {{zh->reconfig == 0}}, we have that each call to {{zoo_cycle_next_server}} 
> moves the address pointer to the next server in {{zh->addrs}}. But, given 
> that {{handle_error}} also moves the pointer to the next server, we end up 
> moving the pointer ahead twice upon every failed attempt to connect, which is 
> wrong.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Backporting ZOOKEEPER-2120 (SSL support) to 3.4.8

[Rakesh Radhakrishnan]

+1(non-binding). Its an interesting idea. I also feel, this would make the
feature development more easy and can attract more users/contributors.

If everyone agrees to this, we could update the project bylaws including
the (1)role & responsibility of feature branch committers, (2)merging back
the feature branch changes to the mainstream (3)branch committer removal
etc.


Rakesh



On Mon, Jul 18, 2016 at 9:51 PM, Flavio Junqueira  wrote:

> That's a great idea, I'm +1.
>
> -Flavio
>
> > On 11 Jul 2016, at 21:13, Patrick Hunt  wrote:
> >
> > I'd like to recommend that we consider a special 3.4 branch for this.
> > (sorry I'm late to the party but I was on vacation till today, just
> back).
> >
> > We could create a 3.4+ssl branch, or something like that, and give
> special
> > permissions for non-committers to commit to the branch. People that are
> > interested in this feature but not committers. Once the folks working on
> > this are satisfied the PMC could do a special "3.4.9+ssl" release
> artifact
> > (say just a tarball), separate from the 3.4.x line, for folks that are
> > interested to use it. This would require minimal oversight by the
> > committers. I believe other components are doing this, typically for
> > feature development before being merged back in, but it would enable
> > interested parties to get access to ssl prior to 3.5 becoming stable. It
> > would also benefit 3.5 in the sense that anything we learn on that branch
> > would be merged into the trunk - fixes say.
> >
> > Patrick
> >
> > On Tue, Jul 5, 2016 at 11:45 AM, Luciano Afranllie <
> listas.luaf...@gmail.com
> >> wrote:
> >
> >> Quick question, ZK-2125 depends on
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2069 and
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2072?
> >>
> >> It seems to be given the description of ZK-2063...
> >>
> >> Regards
> >> Luciano
> >>
> >>
> >> On Fri, Jul 1, 2016 at 12:20 PM, Flavio Junqueira 
> wrote:
> >>
> >>> I think you're talking about porting the patch of ZK-2125. I haven't
> >>> really assessed how much work it would be to backport it, but it is
> >>> possibly not hard.
> >>>
> >>> -Flavio
> >>>
>  On 01 Jul 2016, at 15:54, Luciano Afranllie  >
> >>> wrote:
> 
>  Thanks Flavio
> 
>  What about back porting in our own private fork while we wait for the
> >>> 3.5?
>  I would like your help understanding how easy/difficult this may be.
> 
>  Regards
>  Luciano
> 
>  On Fri, Jul 1, 2016 at 9:23 AM, Flavio Junqueira 
> >> wrote:
> 
> > Hi Luciano,
> >
> > The 3.4 branch is stable and we are only releasing bug fixes at this
> > point, so it is currently not an option to back port.
> >
> > We are all pretty eager to see the 3.5 branch stable, and we are in
> >> the
> > process of voting the release candidate for 3.5.2, but that's still
> >>> tagged
> > as alpha. We don't have a current plan for 3.5.3 yet, but I believe
> no
> >>> one
> > here wants to wait too long have it out. I suspect that it won't be
> >>> before
> > 3 months from now given the pace that we have been releasing, though.
> >
> > -Flavio
> >
> >
> >> On 01 Jul 2016, at 13:07, Luciano Afranllie <
> >> listas.luaf...@gmail.com>
> > wrote:
> >>
> >> Hi there
> >>
> >> We are in the need to have SSL support in Zookeeper in order for our
> >> solution to be FIPS complaint.
> >>
> >> Of course one option is to wait for 3.5 to be released but given we
> >>> are a
> >> little bit time constrained we want to consider an alternative of
> >> backporting SSL support from 3.5 to 3.4 (we are using 3.4.8)
> >>
> >> Do you think this is doable? Can you please tell me the impact of
> >> doing
> >> this and if you think it is a viable alternative? We have experience
> >>> with
> >> Java but not with ZK at development level.
> >>
> >> Of, course if you have a rough estimate about when ZK 3.5 may be
> >>> released
> >> that may help in our decision too.
> >>
> >> Regards
> >> Luciano
> >
> >
> >>>
> >>>
> >>
>
>

Re: Backporting ZOOKEEPER-2120 (SSL support) to 3.4.8

[Flavio Junqueira]

That's a great idea, I'm +1.

-Flavio

> On 11 Jul 2016, at 21:13, Patrick Hunt  wrote:
> 
> I'd like to recommend that we consider a special 3.4 branch for this.
> (sorry I'm late to the party but I was on vacation till today, just back).
> 
> We could create a 3.4+ssl branch, or something like that, and give special
> permissions for non-committers to commit to the branch. People that are
> interested in this feature but not committers. Once the folks working on
> this are satisfied the PMC could do a special "3.4.9+ssl" release artifact
> (say just a tarball), separate from the 3.4.x line, for folks that are
> interested to use it. This would require minimal oversight by the
> committers. I believe other components are doing this, typically for
> feature development before being merged back in, but it would enable
> interested parties to get access to ssl prior to 3.5 becoming stable. It
> would also benefit 3.5 in the sense that anything we learn on that branch
> would be merged into the trunk - fixes say.
> 
> Patrick
> 
> On Tue, Jul 5, 2016 at 11:45 AM, Luciano Afranllie > wrote:
> 
>> Quick question, ZK-2125 depends on
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2069 and
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2072?
>> 
>> It seems to be given the description of ZK-2063...
>> 
>> Regards
>> Luciano
>> 
>> 
>> On Fri, Jul 1, 2016 at 12:20 PM, Flavio Junqueira  wrote:
>> 
>>> I think you're talking about porting the patch of ZK-2125. I haven't
>>> really assessed how much work it would be to backport it, but it is
>>> possibly not hard.
>>> 
>>> -Flavio
>>> 
 On 01 Jul 2016, at 15:54, Luciano Afranllie 
>>> wrote:
 
 Thanks Flavio
 
 What about back porting in our own private fork while we wait for the
>>> 3.5?
 I would like your help understanding how easy/difficult this may be.
 
 Regards
 Luciano
 
 On Fri, Jul 1, 2016 at 9:23 AM, Flavio Junqueira 
>> wrote:
 
> Hi Luciano,
> 
> The 3.4 branch is stable and we are only releasing bug fixes at this
> point, so it is currently not an option to back port.
> 
> We are all pretty eager to see the 3.5 branch stable, and we are in
>> the
> process of voting the release candidate for 3.5.2, but that's still
>>> tagged
> as alpha. We don't have a current plan for 3.5.3 yet, but I believe no
>>> one
> here wants to wait too long have it out. I suspect that it won't be
>>> before
> 3 months from now given the pace that we have been releasing, though.
> 
> -Flavio
> 
> 
>> On 01 Jul 2016, at 13:07, Luciano Afranllie <
>> listas.luaf...@gmail.com>
> wrote:
>> 
>> Hi there
>> 
>> We are in the need to have SSL support in Zookeeper in order for our
>> solution to be FIPS complaint.
>> 
>> Of course one option is to wait for 3.5 to be released but given we
>>> are a
>> little bit time constrained we want to consider an alternative of
>> backporting SSL support from 3.5 to 3.4 (we are using 3.4.8)
>> 
>> Do you think this is doable? Can you please tell me the impact of
>> doing
>> this and if you think it is a viable alternative? We have experience
>>> with
>> Java but not with ZK at development level.
>> 
>> Of, course if you have a rough estimate about when ZK 3.5 may be
>>> released
>> that may help in our decision too.
>> 
>> Regards
>> Luciano
> 
> 
>>> 
>>> 
>> 

ZooKeeper_branch34_solaris - Build # 1221 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_solaris/1221/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 173456 lines...]
[junit] 2016-07-18 14:06:44,323 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-07-18 14:06:44,323 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-07-18 14:06:44,323 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-07-18 14:06:44,324 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-07-18 14:06:44,324 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-07-18 14:06:44,324 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-07-18 14:06:44,324 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-07-18 14:06:44,324 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-07-18 14:06:44,325 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2016-07-18 14:06:44,325 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-07-18 14:06:44,325 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-07-18 14:06:44,326 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-07-18 14:06:44,327 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2016-07-18 14:06:44,327 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-07-18 14:06:44,327 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-07-18 14:06:44,327 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-07-18 14:06:44,328 [myid:] - INFO  [main:ZooKeeperServer@170] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test3892480650238972538.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/trunk/build/test/tmp/test3892480650238972538.junit.dir/version-2
[junit] 2016-07-18 14:06:44,330 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-07-18 14:06:44,331 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:65007
[junit] 2016-07-18 14:06:44,331 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:65007
[junit] 2016-07-18 14:06:44,331 [myid:] - INFO  
[Thread-5:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-07-18 14:06:44,332 [myid:] - INFO  
[Thread-5:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:65007 (no session established for client)
[junit] 2016-07-18 14:06:44,333 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-07-18 14:06:44,334 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-07-18 14:06:44,334 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-07-18 14:06:44,335 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-07-18 14:06:44,335 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-07-18 14:06:44,335 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 9198
[junit] 2016-07-18 14:06:44,336 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-07-18 14:06:44,336 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-07-18 14:06:44,336 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2016-07-18 14:06:44,412 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x155fe5494ab closed
[junit] 2016-07-18 14:06:44,412 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x155fe5494ab
[junit] 2016-07-18 14:06:44,412 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-07-18 14:06:44,414 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-07-18 14:06:44,414 [myid:] - INFO  
[main:SessionTrackerImpl@225] - 

ZooKeeper_branch35_openjdk7 - Build # 155 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_openjdk7/155/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 431401 lines...]
[junit] 2016-07-18 11:27:23,215 [myid:] - INFO  [ProcessThread(sid:0 
cport:11222)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-07-18 11:27:23,216 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-07-18 11:27:23,216 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-07-18 11:27:23,217 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree]
[junit] 2016-07-18 11:27:23,217 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11222]
[junit] 2016-07-18 11:27:23,217 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-07-18 11:27:23,218 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-07-18 11:27:23,223 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 54 at start it was 43
[junit] 2016-07-18 11:27:23,223 [myid:] - INFO  [main:ClientBase@570] - 
sleeping for 20 secs
[junit] 2016-07-18 11:27:23,224 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testQuota
[junit] 2016-07-18 11:27:23,225 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testQuota
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.885 sec

junit.run-concurrent:

junit.run:

test-core-java:

call-test-cppunit:

init:

check-cppunit-makefile:

create-cppunit-makefile:

init:

check-cppunit-configure:

create-cppunit-configure:
 [exec] configure.ac:37: warning: macro `AM_PATH_CPPUNIT' not found in 
library
 [exec] libtoolize: putting auxiliary files in `.'.
 [exec] libtoolize: copying file `./config.guess'
 [exec] libtoolize: copying file `./config.sub'
 [exec] libtoolize: copying file `./install-sh'
 [exec] libtoolize: copying file `./ltmain.sh'
 [exec] libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to 
configure.ac and
 [exec] libtoolize: rerunning libtoolize, to keep the correct libtool 
macros in-tree.
 [exec] libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in 
Makefile.am.
 [exec] configure.ac:37: warning: macro `AM_PATH_CPPUNIT' not found in 
library
 [exec] configure.ac:37: error: possibly undefined macro: AM_PATH_CPPUNIT
 [exec]   If this token and others are legitimate, please use 
m4_pattern_allow.
 [exec]   See the Autoconf documentation.
 [exec] autoreconf: /usr/bin/autoconf failed with exit status: 1

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_openjdk7/branch-3.5/build.xml:1322:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_openjdk7/branch-3.5/build.xml:1281:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_openjdk7/branch-3.5/build.xml:1268:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_openjdk7/branch-3.5/build.xml:1260:
 exec returned: 1

Total time: 75 minutes 27 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

ZooKeeper_branch35_jdk7 - Build # 588 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_jdk7/588/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 101560 lines...]
[junit] 2016-07-18 08:58:17,516 [myid:2] - INFO  
[NIOWorkerThread-2:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:40844 (no session established for client)
[junit] 2016-07-18 08:58:17,613 [myid:] - INFO  [ProcessThread(sid:0 
cport:11222)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x102b56534930008
[junit] 2016-07-18 08:58:17,616 [myid:] - INFO  
[NIOWorkerThread-7:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=Connections,name2=127.0.0.1,name3=0x102b56534930008]
[junit] 2016-07-18 08:58:17,616 [myid:] - INFO  
[BasicHammerThread-8:ZooKeeper@1313] - Session: 0x102b56534930008 closed
[junit] 2016-07-18 08:58:17,617 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x102b56534930008
[junit] 2016-07-18 08:58:17,617 [myid:] - INFO  
[NIOWorkerThread-7:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:47600 which had sessionid 0x102b56534930008
[junit] 2016-07-18 08:58:17,614 [myid:] - INFO  
[HammerThread-28-EventThread:ClientCnxn$EventThread@513] - EventThread shut 
down for session: 0x402b5654b780003
[junit] 2016-07-18 08:58:17,597 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 30436
[junit] 2016-07-18 08:58:17,598 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:/127.0.0.1:30436:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:58066
[junit] 2016-07-18 08:58:17,599 [myid:] - INFO  
[NIOWorkerThread-5:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:58066
[junit] 2016-07-18 08:58:17,600 [myid:] - INFO  
[NIOWorkerThread-5:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:58066 (no session established for client)
[junit] 2016-07-18 08:58:17,625 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49352:LearnerHandler@382] - Follower sid: 1 : info : 
127.0.0.1:30426:30431:participant;127.0.0.1:30436
[junit] 2016-07-18 08:58:17,627 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49353:LearnerHandler@382] - Follower sid: 2 : info : 
127.0.0.1:30427:30432:participant;127.0.0.1:30437
[junit] 2016-07-18 08:58:17,633 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49352:LearnerHandler@683] - Synchronizing with 
Follower sid: 1 maxCommittedLog=0x0 minCommittedLog=0x0 lastProcessedZxid=0x0 
peerLastZxid=0x0
[junit] 2016-07-18 08:58:17,634 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49352:LearnerHandler@727] - Sending DIFF zxid=0x0 
for peer sid: 1
[junit] 2016-07-18 08:58:17,635 [myid:] - INFO  
[QuorumPeer[myid=1](plain=/127.0.0.1:30436)(secure=disabled):Learner@366] - 
Getting a diff from the leader 0x0
[junit] 2016-07-18 08:58:17,635 [myid:] - INFO  
[QuorumPeer[myid=1](plain=/127.0.0.1:30436)(secure=disabled):Learner@509] - 
Learner received NEWLEADER message
[junit] 2016-07-18 08:58:17,638 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49353:LearnerHandler@683] - Synchronizing with 
Follower sid: 2 maxCommittedLog=0x0 minCommittedLog=0x0 lastProcessedZxid=0x0 
peerLastZxid=0x0
[junit] 2016-07-18 08:58:17,638 [myid:] - INFO  
[LearnerHandler-/127.0.0.1:49353:LearnerHandler@727] - Sending DIFF zxid=0x0 
for peer sid: 2
[junit] 2016-07-18 08:58:17,639 [myid:] - INFO  
[QuorumPeer[myid=2](plain=/127.0.0.1:30437)(secure=disabled):Learner@366] - 
Getting a diff from the leader 0x0
[junit] 2016-07-18 08:58:17,639 [myid:] - INFO  
[QuorumPeer[myid=2](plain=/127.0.0.1:30437)(secure=disabled):Learner@509] - 
Learner received NEWLEADER message
[junit] 2016-07-18 08:58:17,644 [myid:] - INFO  
[QuorumPeer[myid=1](plain=/127.0.0.1:30436)(secure=disabled):FileTxnSnapLog@298]
 - Snapshotting: 0x0 to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test4133434640810976784.junit.dir/version-2/snapshot.0
[junit] 2016-07-18 08:58:17,650 [myid:] - INFO  
[QuorumPeer[myid=2](plain=/127.0.0.1:30437)(secure=disabled):FileTxnSnapLog@298]
 - Snapshotting: 0x0 to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test3479841934305193796.junit.dir/version-2/snapshot.0
[junit] 2016-07-18 08:58:17,651 [myid:] - INFO  
[QuorumPeer[myid=3](plain=/127.0.0.1:30438)(secure=disabled):Leader@1249] - 
Have quorum of supporters, sids: [ [1, 3],[1, 3] ]; starting up and setting 
last processed zxid: 0x1
[junit] 2016-07-18 08:58:17,651 [myid:] - INFO  
[QuorumPeer[myid=3](plain=/127.0.0.1:30438)(secure=disabled):QuorumPeer@1481] - 
writeToDisk == true but configFilename == null
[junit] 2016-07-18 08:58:17,652 [myid:] - INFO  

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

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-solaris/1233/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 413594 lines...]
[junit] 2016-07-18 08:49:18,930 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-07-18 08:49:18,931 [myid:] - INFO  [main:ClientBase@466] - 
STARTING server
[junit] 2016-07-18 08:49:18,931 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-07-18 08:49:18,931 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2016-07-18 08:49:18,932 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-07-18 08:49:18,933 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-07-18 08:49:18,933 [myid:] - INFO  [main:ZooKeeperServer@858] 
- minSessionTimeout set to 6000
[junit] 2016-07-18 08:49:18,933 [myid:] - INFO  [main:ZooKeeperServer@867] 
- maxSessionTimeout set to 6
[junit] 2016-07-18 08:49:18,933 [myid:] - INFO  [main:ZooKeeperServer@156] 
- 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/test1267790623173515246.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test1267790623173515246.junit.dir/version-2
[junit] 2016-07-18 08:49:18,934 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test1267790623173515246.junit.dir/version-2/snapshot.b
[junit] 2016-07-18 08:49:18,936 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test1267790623173515246.junit.dir/version-2/snapshot.b
[junit] 2016-07-18 08:49:18,937 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-07-18 08:49:18,938 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:57766
[junit] 2016-07-18 08:49:18,938 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:57766
[junit] 2016-07-18 08:49:18,939 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-07-18 08:49:18,939 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:57766 (no session established for client)
[junit] 2016-07-18 08:49:18,939 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-07-18 08:49:18,940 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-07-18 08:49:18,941 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-07-18 08:49:18,941 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-07-18 08:49:18,941 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-07-18 08:49:18,941 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17718
[junit] 2016-07-18 08:49:18,941 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-07-18 08:49:18,942 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-07-18 08:49:18,942 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-07-18 08:49:19,023 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1227a2e3c1f closed
[junit] 2016-07-18 08:49:19,023 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1227a2e3c1f
[junit] 2016-07-18 08:49:19,024 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-07-18 08:49:19,025 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-07-18 08:49:19,025 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-07-18 08:49:19,025 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] -