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

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 425032 lines...]
[junit] 2016-06-30 06:57:06,458 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-30 06:57:06,459 [myid:] - INFO  [main:ClientBase@466] - 
STARTING server
[junit] 2016-06-30 06:57:06,459 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-06-30 06:57:06,459 [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-06-30 06:57:06,460 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-06-30 06:57:06,460 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-06-30 06:57:06,461 [myid:] - INFO  [main:ZooKeeperServer@858] 
- minSessionTimeout set to 6000
[junit] 2016-06-30 06:57:06,461 [myid:] - INFO  [main:ZooKeeperServer@867] 
- maxSessionTimeout set to 6
[junit] 2016-06-30 06:57:06,461 [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/test5686655813528748785.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test5686655813528748785.junit.dir/version-2
[junit] 2016-06-30 06:57:06,462 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test5686655813528748785.junit.dir/version-2/snapshot.b
[junit] 2016-06-30 06:57:06,464 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test5686655813528748785.junit.dir/version-2/snapshot.b
[junit] 2016-06-30 06:57:06,465 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-06-30 06:57:06,466 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:34799
[junit] 2016-06-30 06:57:06,466 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:34799
[junit] 2016-06-30 06:57:06,466 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-06-30 06:57:06,467 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:34799 (no session established for client)
[junit] 2016-06-30 06:57:06,467 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-30 06:57:06,468 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-06-30 06:57:06,468 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-06-30 06:57:06,468 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-06-30 06:57:06,469 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-06-30 06:57:06,469 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17718
[junit] 2016-06-30 06:57:06,469 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-06-30 06:57:06,469 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-06-30 06:57:06,469 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-06-30 06:57:06,552 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1221d1549ce closed
[junit] 2016-06-30 06:57:06,552 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1221d1549ce
[junit] 2016-06-30 06:57:06,552 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-06-30 06:57:06,553 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-06-30 06:57:06,553 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-06-30 06:57:06,553 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selecto

[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&focusedCommentId=15356603#comment-15356603
 ] 

Rakesh R commented on ZOOKEEPER-1045:
-

Following are few references from hbase and hdfs to get more idea.

I could see Hbase using user/host@realm in their principals, hbase [principal 
format|https://github.com/apache/hbase/blob/master/hbase-common/src/main/resources/hbase-default.xml#L958].
 Also, HDFS has the string comparison logic, 
[SaslRpcServer.java|https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SaslRpcServer.java#L356].
 HDFS [principal 
format|https://github.com/apache/hadoop/blob/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/resources/hdfs-default.xml#L1582].
 I'm wondering how user/host@realm is working in hbase and hdfs. I'm exploring 
more about this part.




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

ZooKeeper_branch35_jdk7 - Build # 569 - Still Failing

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 442020 lines...]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@testLogCallbackInit@993: 
testLogCallbackInit #8]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@testLogCallbackInit@993: 
testLogCallbackInit #9]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@zookeeper_close@3257: Closing 
zookeeper sessionId=0x1006288c2dd000e to [127.0.0.1:22181]
 [exec] ]
 [exec]  : elapsed 1001 : OK
 [exec] Zookeeper_simpleSystem::testLogCallbackClearLog Message Received: 
[2016-06-30 06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1027: Client 
environment:zookeeper.version=zookeeper C client 3.5.2]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1031: Client 
environment:host.name=proserpina.apache.org]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1038: Client 
environment:os.name=Linux]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1039: Client 
environment:os.arch=3.13.0-36-lowlatency]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1040: Client 
environment:os.version=#63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1048: Client 
environment:user.name=jenkins]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1056: Client 
environment:user.home=/home/jenkins]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@log_env@1068: Client 
environment:user.dir=/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/test-cppunit]
 [exec] Log Message Received: [2016-06-30 
06:05:08,730:13508(0x2ad70b912540):ZOO_INFO@zookeeper_init_internal@: 
Initiating client connection, host=127.0.0.1:22181 sessionTimeout=1 
watcher=0x45d2a0 sessionId=0 sessionPasswd= context=0x7dc4ccf0 
flags=0]
 [exec] Log Message Received: [2016-06-30 
06:05:08,731:13508(0x2ad70d96f700):ZOO_INFO@check_events@2357: initiated 
connection to server [127.0.0.1:22181]]
 [exec] Log Message Received: [2016-06-30 
06:05:08,742:13508(0x2ad70d96f700):ZOO_INFO@check_events@2409: session 
establishment complete on server [127.0.0.1:22181], 
sessionId=0x1006288c2dd000f, negotiated timeout=1 ]
 [exec]  : elapsed 1001 : OK
 [exec] Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server 
started : elapsed 10250 : OK
 [exec] Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK
 [exec] Zookeeper_simpleSystem::testFirstServerDown : elapsed 1001 : OK
 [exec] Zookeeper_simpleSystem::testNullData : elapsed 1039 : OK
 [exec] Zookeeper_simpleSystem::testIPV6 : elapsed 1013 : OK
 [exec] Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK
 [exec] Zookeeper_simpleSystem::testPath : elapsed 1049 : OK
 [exec] Zookeeper_simpleSystem::testPathValidation : elapsed 1141 : OK
 [exec] Zookeeper_simpleSystem::testPing : elapsed 17643 : OK
 [exec] Zookeeper_simpleSystem::testAcl : elapsed 1025 : OK
 [exec] Zookeeper_simpleSystem::testChroot : elapsed 4103 : OK
 [exec] Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper 
server started : elapsed 30610 : OK
 [exec] Zookeeper_simpleSystem::testHangingClient : elapsed 1042 : OK
 [exec] Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper 
server started ZooKeeper server started ZooKeeper server started : elapsed 
15043 : OK
 [exec] Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper 
server started ZooKeeper server started ZooKeeper server started : elapsed 
15000 : OK
 [exec] Zookeeper_simpleSystem::testGetChildren2 : elapsed 1071 : OK
 [exec] Zookeeper_simpleSystem::testLastZxid : elapsed 4531 : OK
 [exec] Zookeeper_simpleSystem::testRemoveWatchers ZooKeeper server started 
: elapsed 4337 : OK
 [exec] Zookeeper_readOnly::testReadOnly : elapsed 4125 : OK
 [exec] 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/src/c/tests/TestReconfig.cc:183:
 Assertion: equality assertion failed [Expected: 1, Actual  : 0]
 [exec] Failures !!!
 [exec] Run: 72   Failure total: 1   Failures: 1   Errors: 0
 [exec] FAIL: zktest-mt
 [exec] ==
 [exec] 1 of 2 tests failed
 [exec] Please report to u...@zookeeper.apache.org
 [exec] ==
 [exec] make[1]: Leavi

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Patrick Hunt]

Enrico, I don't believe this would be a blocker for the 3.5.2 release
(correct me if I missed something). Certainly we should fix it, but not a
blocker imo.

Patrick

On Wed, Jun 29, 2016 at 10:40 PM, Enrico Olivelli 
wrote:

> Hi,
> There is also the javacc dep to be removed if it is possible. I don't know
> if I have time today in order to submit a patch
>
> Enrico
>
> Il Gio 30 Giu 2016 06:19 Patrick Hunt  ha scritto:
>
> > I've committed 2458 and 2459 to 3.5 and trunk branches if you want to cut
> > another RC. These two patches addressed the concerns raised by Flavio.
> >
> > Patrick
> >
> > On Wed, Jun 29, 2016 at 2:32 PM, Flavio Junqueira 
> wrote:
> >
> > > -1, In the last update of ZK-2235, we didn't remove
> > > servlet-api-2.5.LICENSE.txt, so the licensing information is incorrect.
> > > I'll submit a patch shortly.
> > >
> > > Since we are on the topic, I'm wondering if we need to bubble up the
> > > contents of the netty notice file as well that comes in the jar.
> Before I
> > > thought that it wasn't necessary as long as the NOTICE is there with
> the
> > > jar, but then someone in the incubator list called the attention to the
> > > fact that we needed to bubble up some info in the notice file. The
> > > instructions I'm aware of aren't super clear:
> > >
> > > http://www.apache.org/dev/licensing-howto.html#alv2-dep
> > >
> > > -Flavio
> > >
> > > > On 29 Jun 2016, at 18:34, Mohammad arshad <
> mohammad.ars...@huawei.com>
> > > wrote:
> > > >
> > > > +1 (non binding)
> > > > Built tar on windows
> > > > Generated docs
> > > > VERFICATION:
> > > > Installed 2 cluster each of 3 zk server
> > > > 1)Tested following scenario for ZOOKEEPER-2139 Multi Client in a JVM
> > > (with 2 clients from the same jvm)
> > > >   i) One client connected to secure, SSL authentication enabled,
> > > cluster other to non-secure cluster
> > > >   Both clients were doing create, delete, get data and set data
> > > simultaneously and continuously
> > > >   ii) One client connected to kerbeors authentication enabled
> > > cluster other to digest authentication enabled cluster
> > > >   Both clients were doing create, delete, get data and set data
> > > simultaneously and continuously
> > > > 2) Following Operations are verified
> > > >   create node (ALL API, All node types)
> > > >   delete node
> > > >   set data
> > > >   get data
> > > >   setAcl
> > > >   getAcl
> > > >   multi operation
> > > >   Few Four letter word commands
> > > > 3) Verified all the JIRA in which I was involved, all are passed
> > > >
> > > > Thanks,
> > > > Arshad
> > > >
> > > > -Original Message-
> > > > From: Patrick Hunt [mailto:ph...@apache.org]
> > > > Sent: 29 June 2016 20:47
> > > > To: DevZooKeeper
> > > > Subject: Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0
> > > >
> > > > Looks like that javacc dependency was added in
> > > > https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have
> > been
> > > build only afaict.
> > > >
> > > > Thanks for reporting this Enrico, would you mind submitting a JIRA
> (and
> > > perhaps a patch)?
> > > >
> > > > Thanks,
> > > >
> > > > Patrick
> > > >
> > > >
> > > > On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli <
> eolive...@gmail.com>
> > > > wrote:
> > > >
> > > >> +1 (non binding)
> > > >> Tested Majordodo (http://majordodo.org) and BlazingCache
> > > >> (http://blazingcache.org) against 3.5.2-alpha.
> > > >>
> > > >> My tests also include running Apache BookKeeper 4.4.0 using the
> > > >> 3.5.2-alpha java client.
> > > >>
> > > >> All is fine but dependencies changed a lot, many legacy deps like
> > > >> jline, jms and sun jmx disappeared and this is very good,
> > > >>
> > > >> but this new dependency showed up:
> > > >> net.java.dev.javacc:javacc:jar:5.0
> > > >>
> > > >> If I exclude javacc all of my tests continue to run fine, my tests
> > > >> cover both java client and embedded single server.
> > > >> Maybe it would be useful to hide the dependency in future release
> but
> > > >> it is not a showstopper for my projects.
> > > >>
> > > >>
> > > >>
> > > >> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
> > > >>> +1 tested SSL support, everything appears to be working as
> expected.
> > > >>>
> > > >>> On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
> > >  +1. sig/xsum are valid, RAT ran clean and no other discrepancies
> > > >> noticed.
> > >  I
> > >  ran it through a number of manual tests (including starting a 23
> > >  server
> > >  ensemble) - no issues found.
> > > 
> > >  Patrick
> > > 
> > >  On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth
> > >  
> > >  wrote:
> > > 
> > > > This is a release candidate for 3.5.2-alpha. The full release
> > > > notes
> > > >> are
> > > > available at:
> > > >
> > > >
> > > >>
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310
> > > >> 801&v
> > > > ersion=12331981
>

[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&focusedCommentId=15356576#comment-15356576
 ] 

Patrick Hunt commented on ZOOKEEPER-1045:
-

No, not that it's insufficient, but I was wondering what else was going on in 
order for a simple string comparison to be used.

For example. String comparison might be fine in that situation - iiuc they are 
comparing ids. If we were to use user/host@realm  principals that would be a 
problem. user@realm should work ok. However if the credentials provided to each 
of the servers is the same (user@realm) that would be a bit less secure than 
providing each of the servers individual credentials with user/host@realm 
principals. In the former case (user/host@realm) we couldn't do a simple string 
comparison without some prior code handling that complexity. Perhaps what hbase 
is doing is using user@realm, I'm not sure, I'll try to find out (lmk if you 
come across it).

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

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Enrico Olivelli]

Hi,
There is also the javacc dep to be removed if it is possible. I don't know
if I have time today in order to submit a patch

Enrico

Il Gio 30 Giu 2016 06:19 Patrick Hunt  ha scritto:

> I've committed 2458 and 2459 to 3.5 and trunk branches if you want to cut
> another RC. These two patches addressed the concerns raised by Flavio.
>
> Patrick
>
> On Wed, Jun 29, 2016 at 2:32 PM, Flavio Junqueira  wrote:
>
> > -1, In the last update of ZK-2235, we didn't remove
> > servlet-api-2.5.LICENSE.txt, so the licensing information is incorrect.
> > I'll submit a patch shortly.
> >
> > Since we are on the topic, I'm wondering if we need to bubble up the
> > contents of the netty notice file as well that comes in the jar. Before I
> > thought that it wasn't necessary as long as the NOTICE is there with the
> > jar, but then someone in the incubator list called the attention to the
> > fact that we needed to bubble up some info in the notice file. The
> > instructions I'm aware of aren't super clear:
> >
> > http://www.apache.org/dev/licensing-howto.html#alv2-dep
> >
> > -Flavio
> >
> > > On 29 Jun 2016, at 18:34, Mohammad arshad 
> > wrote:
> > >
> > > +1 (non binding)
> > > Built tar on windows
> > > Generated docs
> > > VERFICATION:
> > > Installed 2 cluster each of 3 zk server
> > > 1)Tested following scenario for ZOOKEEPER-2139 Multi Client in a JVM
> > (with 2 clients from the same jvm)
> > >   i) One client connected to secure, SSL authentication enabled,
> > cluster other to non-secure cluster
> > >   Both clients were doing create, delete, get data and set data
> > simultaneously and continuously
> > >   ii) One client connected to kerbeors authentication enabled
> > cluster other to digest authentication enabled cluster
> > >   Both clients were doing create, delete, get data and set data
> > simultaneously and continuously
> > > 2) Following Operations are verified
> > >   create node (ALL API, All node types)
> > >   delete node
> > >   set data
> > >   get data
> > >   setAcl
> > >   getAcl
> > >   multi operation
> > >   Few Four letter word commands
> > > 3) Verified all the JIRA in which I was involved, all are passed
> > >
> > > Thanks,
> > > Arshad
> > >
> > > -Original Message-
> > > From: Patrick Hunt [mailto:ph...@apache.org]
> > > Sent: 29 June 2016 20:47
> > > To: DevZooKeeper
> > > Subject: Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0
> > >
> > > Looks like that javacc dependency was added in
> > > https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have
> been
> > build only afaict.
> > >
> > > Thanks for reporting this Enrico, would you mind submitting a JIRA (and
> > perhaps a patch)?
> > >
> > > Thanks,
> > >
> > > Patrick
> > >
> > >
> > > On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli 
> > > wrote:
> > >
> > >> +1 (non binding)
> > >> Tested Majordodo (http://majordodo.org) and BlazingCache
> > >> (http://blazingcache.org) against 3.5.2-alpha.
> > >>
> > >> My tests also include running Apache BookKeeper 4.4.0 using the
> > >> 3.5.2-alpha java client.
> > >>
> > >> All is fine but dependencies changed a lot, many legacy deps like
> > >> jline, jms and sun jmx disappeared and this is very good,
> > >>
> > >> but this new dependency showed up:
> > >> net.java.dev.javacc:javacc:jar:5.0
> > >>
> > >> If I exclude javacc all of my tests continue to run fine, my tests
> > >> cover both java client and embedded single server.
> > >> Maybe it would be useful to hide the dependency in future release but
> > >> it is not a showstopper for my projects.
> > >>
> > >>
> > >>
> > >> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
> > >>> +1 tested SSL support, everything appears to be working as expected.
> > >>>
> > >>> On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
> >  +1. sig/xsum are valid, RAT ran clean and no other discrepancies
> > >> noticed.
> >  I
> >  ran it through a number of manual tests (including starting a 23
> >  server
> >  ensemble) - no issues found.
> > 
> >  Patrick
> > 
> >  On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth
> >  
> >  wrote:
> > 
> > > This is a release candidate for 3.5.2-alpha. The full release
> > > notes
> > >> are
> > > available at:
> > >
> > >
> > >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310
> > >> 801&v
> > > ersion=12331981
> > >
> > > *** Please download, test and vote by July 1st 2016, 23:59 UTC+0.
> > > ***
> > >
> > > Source files:
> > > http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidat
> > > e-0/
> > >
> > > Maven staging repo:
> > >
> > >>
> https://repository.apache.org/content/groups/staging/org/apache/zookee
> > >> per/z
> > > ookeeper/3.5.2-alpha/
> > >
> > > The tag to be voted upon:
> > > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0
> > > /
> > >
> > >

[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&focusedCommentId=15356546#comment-15356546
 ] 

Rakesh R commented on ZOOKEEPER-1045:
-

bq. Regardless we may need to have two such callbacks given the mechanism for 
quorum auth will be different from true client->server auth (authz I mean - acl 
support with kerberos for clients)
Yes, How about introducing {{SaslQuorumCallbackHandler}} for separating out the 
new logic from client-server authz.

bq. The handleAuthz method from hbase seems deceptively simple to me -  there 
must be some setup ahead of time so that the simple string comparison can be 
done?
Sorry, I failed to understand this part. Are you pointing out that the string 
comparison is not sufficient?


> 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-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-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&focusedCommentId=15356528#comment-15356528
 ] 

Patrick Hunt commented on ZOOKEEPER-1045:
-

The handleAuthz method from hbase seems deceptively simple to me - there must 
be some setup ahead of time so that the simple string comparison can be done? 
Regardless we may need to have two such callbacks given the mechanism for 
quorum auth will be different from true client->server auth (authz I mean - acl 
support with kerberos for clients)

> 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-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-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&focusedCommentId=15356519#comment-15356519
 ] 

Rakesh R commented on ZOOKEEPER-1045:
-

bq. Am I reading this right or are we indeed doing authz somewhere?
Thanks for bringing this point. The patch doesn't contains any new logic to do 
the authorization. It is just relying on the existing ZooKeeper 
{{SaslServerCallbackHandler}}, but I understand its not sufficient and could do 
extra verification logic similar to hbase like you mentioned. 
{code}
if (ac != null) {
//...
   if (authid.equals(authzid)) {
  ac.setAuthorized(true);
} else {
  ac.setAuthorized(false);
}
if (ac.isAuthorized()) {
 //...
ac.setAuthorizedID(authzid);
}
}
{code}
Its new to me and will explore more on this. I have quickly gone through the 
link, but I failed to find any unit test case to verify the behavior. Please 
point me if you come across any way to simulate through java unit test. Thanks!.

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

Re: ZRUNTIMEINCONSISTENCY

[Patrick Hunt]

Folks are trying to get more details on the jira. I posted a comment there
with more details:
https://issues.apache.org/jira/browse/ZOOKEEPER-2455?focusedCommentId=15356509&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15356509

Patrick

On Wed, Jun 29, 2016 at 6:46 PM, Pradeepa Kumar 
wrote:

> Thanks All,
> Could you please comment on my below queries for which I logged this bug,
> - when do we get ZRUNTIMEINCONSISTENCY and what does that mean
> - when we get ZRUNTIMEINCONSISTENCY, does  that also means server
> connection is closed ? I see from C bindings src that socket is closed. i
> wanted to confirm.
> appreciate your comments on these.
>

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-2455:
-

bq. when do we get ZRUNTIMEINCONSISTENCY and what does that mean

ZRUNTIMEINCONSISTENCY means that the client received a response with an xid 
that it didn't expect. This shouldn't happen and indicates a bug somewhere. 
"unexpected server response: expected 0x570b82fa, but received 0x570b82f9" 
indicates that time went backward from this client's perspective.

bq. when we get ZRUNTIMEINCONSISTENCY, does that also means server connection 
is closed

yes

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Commented] (ZOOKEEPER-2458) Remove license file for servlet-api dependency

[Hudson (JIRA)]

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

Hudson commented on ZOOKEEPER-2458:
---

FAILURE: Integrated in ZooKeeper-trunk #2980 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2980/])
ZOOKEEPER-2458: Remove license file for servlet-api dependency (fpj via phunt) 
(phunt: 
[http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1750737])
* trunk/CHANGES.txt
* trunk/src/java/lib/servlet-api-2.5.LICENSE.txt


> Remove license file for servlet-api dependency
> --
>
> Key: ZOOKEEPER-2458
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2458
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.6.0
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2458.patch
>
>
> In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to 
> the correct one ALv2, but didn't remove the CDDL license file, which is 
> incorrect. This jira removes the incorrect license file.



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

ZooKeeper-trunk - Build # 2980 - Still Failing

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 443415 lines...]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1038: Client 
environment:os.name=Linux]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1039: Client 
environment:os.arch=3.13.0-36-lowlatency]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1040: Client 
environment:os.version=#63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1048: Client 
environment:user.name=jenkins]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1056: Client 
environment:user.home=/home/jenkins]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@log_env@1068: Client 
environment:user.dir=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b82604b5540):ZOO_INFO@zookeeper_init_internal@: 
Initiating client connection, host=127.0.0.1:22181 sessionTimeout=1 
watcher=0x45d2a0 sessionId=0 sessionPasswd= context=0x7fff595ca710 
flags=0]
 [exec] Log Message Received: [2016-06-30 
04:33:57,677:2860(0x2b8262b44700):ZOO_INFO@check_events@2357: initiated 
connection to server [127.0.0.1:22181]]
 [exec] Log Message Received: [2016-06-30 
04:33:57,689:2860(0x2b8262b44700):ZOO_INFO@check_events@2409: session 
establishment complete on server [127.0.0.1:22181], 
sessionId=0x100f87f339c000f, negotiated timeout=1 ]
 [exec]  : elapsed 1001 : OK
 [exec] Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server 
started : elapsed 10235 : OK
 [exec] Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK
 [exec] Zookeeper_simpleSystem::testFirstServerDown : elapsed 1001 : OK
 [exec] Zookeeper_simpleSystem::testNullData : elapsed 1048 : OK
 [exec] Zookeeper_simpleSystem::testIPV6 : elapsed 1020 : OK
 [exec] Zookeeper_simpleSystem::testCreate : elapsed 1024 : OK
 [exec] Zookeeper_simpleSystem::testPath : elapsed 1058 : OK
 [exec] Zookeeper_simpleSystem::testPathValidation : elapsed 1158 : OK
 [exec] Zookeeper_simpleSystem::testPing : elapsed 17651 : OK
 [exec] Zookeeper_simpleSystem::testAcl : elapsed 1023 : OK
 [exec] Zookeeper_simpleSystem::testChroot : elapsed 3083 : OK
 [exec] terminate called after throwing an instance of 'CppUnit::Exception'
 [exec]   what():  equality assertion failed
 [exec] - Expected: 0
 [exec] - Actual  : -116
 [exec] 
 [exec] /bin/bash: line 5:  2860 Aborted 
ZKROOT=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/../.. 
CLASSPATH=$CLASSPATH:$CLOVER_HOME/lib/clover.jar ${dir}$tst
 [exec] Zookeeper_simpleSystem::testAuthFAIL: zktest-mt
 [exec] ==
 [exec] 1 of 2 tests failed
 [exec] Please report to u...@zookeeper.apache.org
 [exec] ==
 [exec] make[1]: Leaving directory 
`/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit'
 [exec] make[1]: *** [check-TESTS] Error 1
 [exec] make: *** [check-am] Error 2

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

Total time: 16 minutes 46 seconds
Build step 'Execute shell' marked build as failure
[FINDBUGS] Skipping publisher since build result is FAILURE
[WARNINGS] Skipping publisher since build result is FAILURE
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording fingerprints
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Updating ZOOKEEPER-2459
Updating ZOOKEEPER-2458
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Publishing Javadoc
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
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



###
###

[jira] [Commented] (ZOOKEEPER-2459) Update NOTICE file with Netty notice

[Hudson (JIRA)]

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

Hudson commented on ZOOKEEPER-2459:
---

FAILURE: Integrated in ZooKeeper-trunk #2980 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2980/])
ZOOKEEPER-2459: Update NOTICE file with Netty notice (fpj via phunt) (phunt: 
[http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1750739])
* trunk/CHANGES.txt
* trunk/src/NOTICE.txt


> Update NOTICE file with Netty notice
> 
>
> Key: ZOOKEEPER-2459
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2459
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2459.patch
>
>
> Bubbling up the Netty notice. According to the ALv2 item 4, we need to 
> include it in our top notice, it isn't sufficient to have it in the bundle. 



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

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Patrick Hunt]

I've committed 2458 and 2459 to 3.5 and trunk branches if you want to cut
another RC. These two patches addressed the concerns raised by Flavio.

Patrick

On Wed, Jun 29, 2016 at 2:32 PM, Flavio Junqueira  wrote:

> -1, In the last update of ZK-2235, we didn't remove
> servlet-api-2.5.LICENSE.txt, so the licensing information is incorrect.
> I'll submit a patch shortly.
>
> Since we are on the topic, I'm wondering if we need to bubble up the
> contents of the netty notice file as well that comes in the jar. Before I
> thought that it wasn't necessary as long as the NOTICE is there with the
> jar, but then someone in the incubator list called the attention to the
> fact that we needed to bubble up some info in the notice file. The
> instructions I'm aware of aren't super clear:
>
> http://www.apache.org/dev/licensing-howto.html#alv2-dep
>
> -Flavio
>
> > On 29 Jun 2016, at 18:34, Mohammad arshad 
> wrote:
> >
> > +1 (non binding)
> > Built tar on windows
> > Generated docs
> > VERFICATION:
> > Installed 2 cluster each of 3 zk server
> > 1)Tested following scenario for ZOOKEEPER-2139 Multi Client in a JVM
> (with 2 clients from the same jvm)
> >   i) One client connected to secure, SSL authentication enabled,
> cluster other to non-secure cluster
> >   Both clients were doing create, delete, get data and set data
> simultaneously and continuously
> >   ii) One client connected to kerbeors authentication enabled
> cluster other to digest authentication enabled cluster
> >   Both clients were doing create, delete, get data and set data
> simultaneously and continuously
> > 2) Following Operations are verified
> >   create node (ALL API, All node types)
> >   delete node
> >   set data
> >   get data
> >   setAcl
> >   getAcl
> >   multi operation
> >   Few Four letter word commands
> > 3) Verified all the JIRA in which I was involved, all are passed
> >
> > Thanks,
> > Arshad
> >
> > -Original Message-
> > From: Patrick Hunt [mailto:ph...@apache.org]
> > Sent: 29 June 2016 20:47
> > To: DevZooKeeper
> > Subject: Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0
> >
> > Looks like that javacc dependency was added in
> > https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have been
> build only afaict.
> >
> > Thanks for reporting this Enrico, would you mind submitting a JIRA (and
> perhaps a patch)?
> >
> > Thanks,
> >
> > Patrick
> >
> >
> > On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli 
> > wrote:
> >
> >> +1 (non binding)
> >> Tested Majordodo (http://majordodo.org) and BlazingCache
> >> (http://blazingcache.org) against 3.5.2-alpha.
> >>
> >> My tests also include running Apache BookKeeper 4.4.0 using the
> >> 3.5.2-alpha java client.
> >>
> >> All is fine but dependencies changed a lot, many legacy deps like
> >> jline, jms and sun jmx disappeared and this is very good,
> >>
> >> but this new dependency showed up:
> >> net.java.dev.javacc:javacc:jar:5.0
> >>
> >> If I exclude javacc all of my tests continue to run fine, my tests
> >> cover both java client and embedded single server.
> >> Maybe it would be useful to hide the dependency in future release but
> >> it is not a showstopper for my projects.
> >>
> >>
> >>
> >> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
> >>> +1 tested SSL support, everything appears to be working as expected.
> >>>
> >>> On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
>  +1. sig/xsum are valid, RAT ran clean and no other discrepancies
> >> noticed.
>  I
>  ran it through a number of manual tests (including starting a 23
>  server
>  ensemble) - no issues found.
> 
>  Patrick
> 
>  On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth
>  
>  wrote:
> 
> > This is a release candidate for 3.5.2-alpha. The full release
> > notes
> >> are
> > available at:
> >
> >
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310
> >> 801&v
> > ersion=12331981
> >
> > *** Please download, test and vote by July 1st 2016, 23:59 UTC+0.
> > ***
> >
> > Source files:
> > http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidat
> > e-0/
> >
> > Maven staging repo:
> >
> >> https://repository.apache.org/content/groups/staging/org/apache/zookee
> >> per/z
> > ookeeper/3.5.2-alpha/
> >
> > The tag to be voted upon:
> > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0
> > /
> >
> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> > http://www.apache.org/dist/zookeeper/KEYS
> >
> > Should we release this candidate?
> >
> >
> > --Chris Nauroth
> >
> >
> >>
>
>

Re: ZK-2458 and ZK-2459

[Patrick Hunt]

Thanks Flavio. I reviewed/committed both of them.

Patrick

On Wed, Jun 29, 2016 at 4:03 PM, Flavio Junqueira  wrote:

> I have submitted two patches to fix the license issues I found. Id'
> appreciate if someone could have a look at them and possibly check them in
> if LG.
>
> Thanks,
> -Flavio

[jira] [Updated] (ZOOKEEPER-2458) Remove license file for servlet-api dependency

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2458:

Affects Version/s: 3.6.0
   3.5.2

> Remove license file for servlet-api dependency
> --
>
> Key: ZOOKEEPER-2458
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2458
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.2, 3.6.0
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2458.patch
>
>
> In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to 
> the correct one ALv2, but didn't remove the CDDL license file, which is 
> incorrect. This jira removes the incorrect license file.



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

ZooKeeper_branch34_jdk7 - Build # 1135 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk7/1135/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 222688 lines...]
[junit] 2016-06-30 02:42:12,051 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-06-30 02:42:12,051 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-06-30 02:42:12,051 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-06-30 02:42:12,052 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2016-06-30 02:42:12,052 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-06-30 02:42:12,052 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-30 02:42:12,053 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-30 02:42:12,055 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2016-06-30 02:42:12,055 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-06-30 02:42:12,056 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-06-30 02:42:12,056 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-06-30 02:42:12,056 [myid:] - INFO  [main:ZooKeeperServer@170] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test8580323808262840789.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test8580323808262840789.junit.dir/version-2
[junit] 2016-06-30 02:42:12,061 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-30 02:42:12,062 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:59749
[junit] 2016-06-30 02:42:12,062 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:59749
[junit] 2016-06-30 02:42:12,063 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-06-30 02:42:12,063 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:59749 (no session established for client)
[junit] 2016-06-30 02:42:12,064 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-30 02:42:12,066 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-06-30 02:42:12,066 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-06-30 02:42:12,066 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-30 02:42:12,066 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-30 02:42:12,067 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 32623
[junit] 2016-06-30 02:42:12,067 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-06-30 02:42:12,067 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-06-30 02:42:12,067 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2016-06-30 02:42:12,133 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x1559f2f66b6 closed
[junit] 2016-06-30 02:42:12,133 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-30 02:42:12,134 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x1559f2f66b6
[junit] 2016-06-30 02:42:12,134 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-06-30 02:42:12,134 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-06-30 02:42:12,134 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-06-30 02:42:12,134 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-06-30 02:42:12,135 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-06-30 02:42:12,135 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-06-30 02:42:12,135 [myid:] - INFO  
[SyncThread:0:Sy

Re: [jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Pradeepa Kumar]

Thanks All,
Could you please comment on my below queries for which I logged this bug,
- when do we get ZRUNTIMEINCONSISTENCY and what does that mean
- when we get ZRUNTIMEINCONSISTENCY, does  that also means server
connection is closed ? I see from C bindings src that socket is closed. i
wanted to confirm.
appreciate your comments on these.

On Thu, Jun 30, 2016 at 2:42 AM, Marshall McMullen (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/ZOOKEEPER-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355782#comment-15355782
> ]
>
> Marshall McMullen commented on ZOOKEEPER-2455:
> --
>
> Oh, neat! I was not aware of that. Thanks for filling in the gaps for me
> Alex.
>
> > unexpected server response ZRUNTIMEINCONSISTENCY
> > 
> >
> > Key: ZOOKEEPER-2455
> > URL:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> > Project: ZooKeeper
> >  Issue Type: Bug
> >  Components: c client
> >Affects Versions: 3.5.1
> >Reporter: pradeep
> > Fix For: 3.5.3, 3.6.0
> >
> >
> > Hi Folks,
> > I am hitting an error in my C client code and below are the set of
> operations I perform:
> >   1.  Zookeeper Client connected to Zookeeper server S1 and a new server
> S2 gets added.
> >   2.  monitor zookeeper server config at the client and on change of
> server config, call zoo_set_server
> > from the client
> >   3.  client can issue operations like zoo_get just after the call to
> zoo_set_servers
> >   4.  I can see that the zookeeper thread logs connect to the new server
> just after the zoo_get
> > call
> > 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345:
> initiated connection
> > to server [128.0.0.5:61728]
> > 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397:
> session establishment
> > complete on server [128.0.0.5:61728], sessionId=0x401852c000c,
> negotiated timeout=2
> >   5.  Some times I find errors like below:
> > 2016-04-11
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923:
> Socket [128.0.0.5:61728]
> > zk retcode=-2, errno=115(Operation now in progress): unexpected server
> response: expected
> > 0x570b82fa, but received 0x570b82f9
> >   1.
> > zoo_get returns (-2) indicating that ZRUNTIMEINCONSISTENCY<
> http://zookeeper.sourcearchive.com/documentation/3.2.2plus-pdfsg3/zookeeper_8h_bb1a0a179f313b2e44ee92369c438a4c.html#bb1a0a179f313b2e44ee92369c438a4c9eabb281ab14c74db3aff9ab456fa7fe
> >
> > What is the issue here? should I be retry the operation zoo_get
> operation? Or should I wait
> > for the zoo_set_server to complete (like wait for the connection
> establishment notification)
> > Thanks,
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

ZRUNTIMEINCONSISTENCY

[Pradeepa Kumar]

Thanks All,
Could you please comment on my below queries for which I logged this bug,
- when do we get ZRUNTIMEINCONSISTENCY and what does that mean
- when we get ZRUNTIMEINCONSISTENCY, does  that also means server
connection is closed ? I see from C bindings src that socket is closed. i
wanted to confirm.
appreciate your comments on these.

ZooKeeper_branch34 - Build # 1566 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34/1566/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 218395 lines...]
[junit] 2016-06-30 00:22:35,311 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-30 00:22:35,311 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-30 00:22:35,312 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-06-30 00:22:35,312 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-06-30 00:22:35,312 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-06-30 00:22:35,312 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-06-30 00:22:35,313 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-06-30 00:22:35,313 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-06-30 00:22:35,313 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2016-06-30 00:22:35,314 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-06-30 00:22:35,315 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-30 00:22:35,315 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-30 00:22:35,317 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2016-06-30 00:22:35,317 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-06-30 00:22:35,318 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-06-30 00:22:35,318 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-06-30 00:22:35,319 [myid:] - INFO  [main:ZooKeeperServer@170] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/branch-3.4/build/test/tmp/test4699385837808155477.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/branch-3.4/build/test/tmp/test4699385837808155477.junit.dir/version-2
[junit] 2016-06-30 00:22:35,324 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-30 00:22:35,325 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:41643
[junit] 2016-06-30 00:22:35,325 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:41643
[junit] 2016-06-30 00:22:35,326 [myid:] - INFO  
[Thread-5:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-06-30 00:22:35,326 [myid:] - INFO  
[Thread-5:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:41643 (no session established for client)
[junit] 2016-06-30 00:22:35,326 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-30 00:22:35,328 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-06-30 00:22:35,329 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-06-30 00:22:35,329 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-30 00:22:35,329 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-30 00:22:35,330 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 31174
[junit] 2016-06-30 00:22:35,330 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-06-30 00:22:35,330 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-06-30 00:22:35,330 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2016-06-30 00:22:35,394 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x1559eaf9518 closed
[junit] 2016-06-30 00:22:35,394 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-30 00:22:35,394 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x1559eaf9518
[junit] 2016-06-30 00:22:35,394 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 20

[jira] [Commented] (ZOOKEEPER-2459) Update NOTICE file with Netty notice

[Michael Han (JIRA)]

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

Michael Han commented on ZOOKEEPER-2459:


lgtm - cross checked with Netty 3.10.5 notice file.

> Update NOTICE file with Netty notice
> 
>
> Key: ZOOKEEPER-2459
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2459
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2459.patch
>
>
> Bubbling up the Netty notice. According to the ALv2 item 4, we need to 
> include it in our top notice, it isn't sufficient to have it in the bundle. 



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Michael Han (JIRA)]

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

Michael Han commented on ZOOKEEPER-2447:


I see, thanks for pointing out this use case. 

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

Failed: ZOOKEEPER-2459 PreCommit Build #3257

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 440269 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/3257//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3257//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3257//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] 55c6667db675e2d3ecc4402bdf222492384a1291 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: 17 minutes 40 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-2459
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-2459) Update NOTICE file with Netty notice

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-2459:
--

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

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

This message is automatically generated.

> Update NOTICE file with Netty notice
> 
>
> Key: ZOOKEEPER-2459
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2459
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2459.patch
>
>
> Bubbling up the Netty notice. According to the ALv2 item 4, we need to 
> include it in our top notice, it isn't sufficient to have it in the bundle. 



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

[jira] [Commented] (ZOOKEEPER-2458) Remove license file for servlet-api dependency

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-2458:
--

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

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

This message is automatically generated.

> Remove license file for servlet-api dependency
> --
>
> Key: ZOOKEEPER-2458
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2458
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2458.patch
>
>
> In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to 
> the correct one ALv2, but didn't remove the CDDL license file, which is 
> incorrect. This jira removes the incorrect license file.



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

Failed: ZOOKEEPER-2458 PreCommit Build #3256

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 436831 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/3256//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3256//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3256//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] e9e2bfd7b3cd9693d3d24ead38ffe0821be0eb96 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 14 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-2458
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

ZooKeeper-trunk - Build # 2979 - Still Failing

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 442841 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-06-29 23:26:59,418 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port24931,name1=Connections,name2=127.0.0.1,name3=0x102401f0cce]
[junit] 2016-06-29 23:26:59,518 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x102401f0cce closed
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 133084
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1641
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-06-29 23:26:59,519 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:24931
[junit] 2016-06-29 23:26:59,518 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x102401f0cce
[junit] 2016-06-29 23:26:59,524 [myid:] - INFO  [main:ZooKeeperServer@498] 
- shutting down
[junit] 2016-06-29 23:26:59,524 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-06-29 23:26:59,524 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  [ProcessThread(sid:0 
cport:24931)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port24931,name1=InMemoryDataTree]
[junit] 2016-06-29 23:26:59,525 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port24931]
[junit] 2016-06-29 23:26:59,526 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 24931
[junit] 2016-06-29 23:26:59,526 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-29 23:26:59,531 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 4814 at start it was 4818
[junit] 2016-06-29 23:26:59,531 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-06-29 23:26:59,531 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
402.85 sec, Thread: 6, 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:
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build.xml:1207:

ZK-2458 and ZK-2459

[Flavio Junqueira]

I have submitted two patches to fix the license issues I found. Id' appreciate 
if someone could have a look at them and possibly check them in if LG.

Thanks,
-Flavio

ZooKeeper_branch34_jdk8 - Build # 616 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk8/616/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 221717 lines...]
[junit] 2016-06-29 22:58:32,099 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-29 22:58:32,100 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-29 22:58:32,100 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-29 22:58:32,100 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-06-29 22:58:32,100 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-06-29 22:58:32,100 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-06-29 22:58:32,101 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-06-29 22:58:32,101 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-06-29 22:58:32,101 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-06-29 22:58:32,101 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2016-06-29 22:58:32,102 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-06-29 22:58:32,102 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-29 22:58:32,103 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-29 22:58:32,104 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2016-06-29 22:58:32,105 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-06-29 22:58:32,105 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-06-29 22:58:32,105 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-06-29 22:58:32,106 [myid:] - INFO  [main:ZooKeeperServer@170] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test410633850334627953.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk8/branch-3.4/build/test/tmp/test410633850334627953.junit.dir/version-2
[junit] 2016-06-29 22:58:32,109 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-29 22:58:32,110 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:47236
[junit] 2016-06-29 22:58:32,110 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:47236
[junit] 2016-06-29 22:58:32,111 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-06-29 22:58:32,111 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:47236 (no session established for client)
[junit] 2016-06-29 22:58:32,111 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-29 22:58:32,113 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-06-29 22:58:32,113 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-06-29 22:58:32,114 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-29 22:58:32,114 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-29 22:58:32,114 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 5750
[junit] 2016-06-29 22:58:32,115 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-06-29 22:58:32,115 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-06-29 22:58:32,115 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2016-06-29 22:58:32,184 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x1559e62a0fe closed
[junit] 2016-06-29 22:58:32,185 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-29 22:58:32,184 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x1559e62a0fe
[junit] 2016-06-29 22:58:32,185 [myid:] - INFO  
[NIOServerCxn.

[jira] [Updated] (ZOOKEEPER-2459) Update NOTICE file with Netty notice

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira updated ZOOKEEPER-2459:

Attachment: ZOOKEEPER-2459.patch

> Update NOTICE file with Netty notice
> 
>
> Key: ZOOKEEPER-2459
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2459
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2459.patch
>
>
> Bubbling up the Netty notice. According to the ALv2 item 4, we need to 
> include it in our top notice, it isn't sufficient to have it in the bundle. 



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

[jira] [Created] (ZOOKEEPER-2459) Update NOTICE file with Netty notice

[Flavio Junqueira (JIRA)]

Flavio Junqueira created ZOOKEEPER-2459:
---

 Summary: Update NOTICE file with Netty notice
 Key: ZOOKEEPER-2459
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2459
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Flavio Junqueira
Assignee: Flavio Junqueira
Priority: Blocker
 Fix For: 3.5.2, 3.6.0


Bubbling up the Netty notice. According to the ALv2 item 4, we need to include 
it in our top notice, it isn't sufficient to have it in the bundle. 



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2447:
---

{quote}
 It will add unnecessary additional latency (the RTT latency for TCP handshake) 
and overhead to every connection, even successful ones where the ensemble isn't 
suffering due to a down host; it'll also put a little extra load on the 
servers, not just clients.
{quote}

Hi [~dbenediktson], 

Yeah... I was aware of the extra pressure on the servers and, to some degree, 
the cost of opening a ephemeral TCP connection on each server of my proposed 
workaround. :( OTOH, {{InetAddress#isReachable()}} (quoting javadocs) will: 
{quote} (try to) use ICMP ECHO REQUESTs if the privilege can be obtained, 
otherwise it will try to establish a TCP connection on port 7 {quote}

If [~vishk] don't oppose, I am more than happy to see your patch for that part. 
:) In the meanwhile, I will dig {{ClientCnxnSocket}} further more following 
your guidelines.

Cheers,
Ed

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Resolved] (ZOOKEEPER-2457) Remove license file for servlet-api dependency

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira resolved ZOOKEEPER-2457.
-
Resolution: Duplicate

> Remove license file for servlet-api dependency
> --
>
> Key: ZOOKEEPER-2457
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2457
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.2, 3.6.0
>
>
> In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to 
> the correct one ALv2, but didn't remove the CDDL license file, which is 
> incorrect. This jira removes the incorrect license file.



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

[jira] [Updated] (ZOOKEEPER-2458) Remove license file for servlet-api dependency

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira updated ZOOKEEPER-2458:

Attachment: ZOOKEEPER-2458.patch

> Remove license file for servlet-api dependency
> --
>
> Key: ZOOKEEPER-2458
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2458
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2458.patch
>
>
> In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to 
> the correct one ALv2, but didn't remove the CDDL license file, which is 
> incorrect. This jira removes the incorrect license file.



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

[jira] [Created] (ZOOKEEPER-2458) Remove license file for servlet-api dependency

[Flavio Junqueira (JIRA)]

Flavio Junqueira created ZOOKEEPER-2458:
---

 Summary: Remove license file for servlet-api dependency
 Key: ZOOKEEPER-2458
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2458
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Flavio Junqueira
Assignee: Flavio Junqueira
 Fix For: 3.5.2, 3.6.0


In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to the 
correct one ALv2, but didn't remove the CDDL license file, which is incorrect. 
This jira removes the incorrect license file.



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

[jira] [Created] (ZOOKEEPER-2457) Remove license file for servlet-api dependency

[Flavio Junqueira (JIRA)]

Flavio Junqueira created ZOOKEEPER-2457:
---

 Summary: Remove license file for servlet-api dependency
 Key: ZOOKEEPER-2457
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2457
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Flavio Junqueira
Assignee: Flavio Junqueira
 Fix For: 3.5.2, 3.6.0


In ZOOKEEPER-2235, we changed the license of the servlet-api dependency to the 
correct one ALv2, but didn't remove the CDDL license file, which is incorrect. 
This jira removes the incorrect license file.



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

[jira] [Issue Comment Deleted] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Dan Benediktson (JIRA)]

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

Dan Benediktson updated ZOOKEEPER-2447:
---
Comment: was deleted

(was: Given that the goal is to open a socket, implementing an isReachable() 
method which is just opening a socket with a timeout seems wasteful. It will 
add unnecessary additional latency (the RTT latency for TCP handshake) and 
overhead to every connection, even successful ones where the ensemble isn't 
suffering due to a down host; it'll also put a little extra load on the 
servers, not just clients. Would it make sense to make ClientCnxnSocket.open() 
implementations apply the timeout directly?

As far as choosing the connection timeout to use, I would suggest just using 
the time-sliced session timeout (I thought this was already done, but perhaps 
it's only applied later in the connection handshake?) but applying some 
reasonable lower bound (say, default of 1 second and overridable by a Java 
system property). We actually have a fork of the ZK code which has that minimum 
bound for connection timeout logic in the Java client, and I'd be happy to 
prepare a patch for that part. It's pretty trivial code, but it's important if 
you start using a combination of large ZK clusters and very small session 
timeouts, which we have in some of our ensembles.)

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Dan Benediktson (JIRA)]

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

Dan Benediktson commented on ZOOKEEPER-2447:


Given that the goal is to open a socket, implementing an isReachable() method 
which is just opening a socket with a timeout seems wasteful. It will add 
unnecessary additional latency (the RTT latency for TCP handshake) and overhead 
to every connection, even successful ones where the ensemble isn't suffering 
due to a down host; it'll also put a little extra load on the servers, not just 
clients. Would it make sense to make ClientCnxnSocket.open() implementations 
apply the timeout directly?

As far as choosing the connection timeout to use, I would suggest just using 
the time-sliced session timeout (I thought this was already done, but perhaps 
it's only applied later in the connection handshake?) but applying some 
reasonable lower bound (say, default of 1 second and overridable by a Java 
system property). We actually have a fork of the ZK code which has that minimum 
bound for connection timeout logic in the Java client, and I'd be happy to 
prepare a patch for that part. It's pretty trivial code, but it's important if 
you start using a combination of large ZK clusters and very small session 
timeouts, which we have in some of our ensembles.

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Dan Benediktson (JIRA)]

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

Dan Benediktson commented on ZOOKEEPER-2447:


Given that the goal is to open a socket, implementing an isReachable() method 
which is just opening a socket with a timeout seems wasteful. It will add 
unnecessary additional latency (the RTT latency for TCP handshake) and overhead 
to every connection, even successful ones where the ensemble isn't suffering 
due to a down host; it'll also put a little extra load on the servers, not just 
clients. Would it make sense to make ClientCnxnSocket.open() implementations 
apply the timeout directly?

As far as choosing the connection timeout to use, I would suggest just using 
the time-sliced session timeout (I thought this was already done, but perhaps 
it's only applied later in the connection handshake?) but applying some 
reasonable lower bound (say, default of 1 second and overridable by a Java 
system property). We actually have a fork of the ZK code which has that minimum 
bound for connection timeout logic in the Java client, and I'd be happy to 
prepare a patch for that part. It's pretty trivial code, but it's important if 
you start using a combination of large ZK clusters and very small session 
timeouts, which we have in some of our ensembles.

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Flavio Junqueira]

-1, In the last update of ZK-2235, we didn't remove 
servlet-api-2.5.LICENSE.txt, so the licensing information is incorrect. I'll 
submit a patch shortly. 

Since we are on the topic, I'm wondering if we need to bubble up the contents 
of the netty notice file as well that comes in the jar. Before I thought that 
it wasn't necessary as long as the NOTICE is there with the jar, but then 
someone in the incubator list called the attention to the fact that we needed 
to bubble up some info in the notice file. The instructions I'm aware of aren't 
super clear:

http://www.apache.org/dev/licensing-howto.html#alv2-dep 

-Flavio

> On 29 Jun 2016, at 18:34, Mohammad arshad  wrote:
> 
> +1 (non binding)
> Built tar on windows
> Generated docs
> VERFICATION:
> Installed 2 cluster each of 3 zk server
> 1)Tested following scenario for ZOOKEEPER-2139 Multi Client in a JVM (with 2 
> clients from the same jvm)
>   i) One client connected to secure, SSL authentication enabled, cluster 
> other to non-secure cluster
>   Both clients were doing create, delete, get data and set data  
> simultaneously and continuously
>   ii) One client connected to kerbeors authentication enabled cluster 
> other to digest authentication enabled cluster
>   Both clients were doing create, delete, get data and set data  
> simultaneously and continuously 
> 2) Following Operations are verified
>   create node (ALL API, All node types)
>   delete node
>   set data
>   get data
>   setAcl
>   getAcl
>   multi operation
>   Few Four letter word commands
> 3) Verified all the JIRA in which I was involved, all are passed
> 
> Thanks,
> Arshad
> 
> -Original Message-
> From: Patrick Hunt [mailto:ph...@apache.org] 
> Sent: 29 June 2016 20:47
> To: DevZooKeeper
> Subject: Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0
> 
> Looks like that javacc dependency was added in
> https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have been build 
> only afaict.
> 
> Thanks for reporting this Enrico, would you mind submitting a JIRA (and 
> perhaps a patch)?
> 
> Thanks,
> 
> Patrick
> 
> 
> On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli 
> wrote:
> 
>> +1 (non binding)
>> Tested Majordodo (http://majordodo.org) and BlazingCache
>> (http://blazingcache.org) against 3.5.2-alpha.
>> 
>> My tests also include running Apache BookKeeper 4.4.0 using the 
>> 3.5.2-alpha java client.
>> 
>> All is fine but dependencies changed a lot, many legacy deps like 
>> jline, jms and sun jmx disappeared and this is very good,
>> 
>> but this new dependency showed up:
>> net.java.dev.javacc:javacc:jar:5.0
>> 
>> If I exclude javacc all of my tests continue to run fine, my tests 
>> cover both java client and embedded single server.
>> Maybe it would be useful to hide the dependency in future release but 
>> it is not a showstopper for my projects.
>> 
>> 
>> 
>> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
>>> +1 tested SSL support, everything appears to be working as expected.
>>> 
>>> On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
 +1. sig/xsum are valid, RAT ran clean and no other discrepancies
>> noticed.
 I
 ran it through a number of manual tests (including starting a 23 
 server
 ensemble) - no issues found.
 
 Patrick
 
 On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth 
 
 wrote:
 
> This is a release candidate for 3.5.2-alpha. The full release 
> notes
>> are
> available at:
> 
> 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310
>> 801&v
> ersion=12331981
> 
> *** Please download, test and vote by July 1st 2016, 23:59 UTC+0. 
> ***
> 
> Source files:
> http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidat
> e-0/
> 
> Maven staging repo:
> 
>> https://repository.apache.org/content/groups/staging/org/apache/zookee
>> per/z
> ookeeper/3.5.2-alpha/
> 
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0
> /
> 
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
> 
> Should we release this candidate?
> 
> 
> --Chris Nauroth
> 
> 
>> 

Re: [jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Edward Ribeiro]

Hi Dan,

The Apache JIRA is undergoing some issues (see here
https://twitter.com/infrabot ) , but looks like it has come back.

Would you mind to repost this message there? :)

Cheers,
Ed

On Wed, Jun 29, 2016 at 5:46 PM, Dan Benediktson <
dbenedikt...@twitter.com.invalid> wrote:

> Apologies for sending this on the mail list instead of through a comment on
> the JIRA - I can't seem to get https://issues.apache.org/jira/ to load for
> me.
>
> Given that the goal is to open a socket, implementing an isReachable()
> method which is just opening a socket with a timeout seems wasteful. It
> will add unnecessary additional latency (the RTT latency for TCP handshake)
> and overhead to every connection, even successful ones where the ensemble
> isn't suffering due to a down host; it'll also put a little extra load on
> the servers, not just clients. Would it make sense to make
> ClientCnxnSocket.open() implementations apply the timeout directly?
>
> As far as choosing the connection timeout to use, I would suggest just
> using the time-sliced session timeout (I thought this was already done, but
> perhaps it's only applied later in the connection handshake?) but applying
> some reasonable lower bound (say, default of 1 second and overridable by a
> Java system property). We actually have a fork of the ZK code which has
> that minimum bound for connection timeout logic in the Java client, and I'd
> be happy to prepare a patch for that part. It's pretty trivial code, but
> it's important if you start using a combination of large ZK clusters and
> very small session timeouts, which we have in some of our ensembles.
>
> Thanks,
> Dan
>
> On Wed, Jun 29, 2016 at 12:27 PM, Andrew Purtell (JIRA) 
> wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/ZOOKEEPER-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355708#comment-15355708
> > ]
> >
> > Andrew Purtell commented on ZOOKEEPER-2447:
> > ---
> >
> > bq. An alternative would be to roll out our own equivalent of
> > {{InetAddress#isReachable()}} as I scribbled below?
> > Makes sense.
> >
> > > Zookeeper adds  good delay when one of the quorum host is not reachable
> > > ---
> > >
> > > Key: ZOOKEEPER-2447
> > > URL:
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> > > Project: ZooKeeper
> > >  Issue Type: Bug
> > >Affects Versions: 3.4.6, 3.5.0
> > >Reporter: Vishal Khandelwal
> > >Assignee: Vishal Khandelwal
> > > Fix For: 3.5.3, 3.6.0
> > >
> > > Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt,
> > withoutFix.txt
> > >
> > >
> > > StaticHostProvider --> resolveAndShuffle method adds all of the address
> > which are valid in the quorum to the list, shuffles them and sends back
> to
> > client connection class. If after shuffling if first node appear to be
> the
> > one which is not reachable, Clientcnx.SendThread.run will keep on
> > connecting to the failure till a timeout and the moves to a different
> node.
> > This adds up random delay in zookeeper connection in case a host is down.
> > Rather we could check if host is reachable in StaticHostProvider and
> ignore
> > isReachable is false. Same as we do for UnknownHostException Exception.
> > > This can tested using following test code by providing a valid host
> > which is not reachable. for quick test comment
> Collections.shuffle(tmpList,
> > sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> > > {code}
> > >  @Test
> > >   public void test() throws Exception {
> > > EventsWatcher watcher = new EventsWatcher();
> > > QuorumUtil qu = new QuorumUtil(1);
> > > qu.startAll();
> > >
> > > ZooKeeper zk =
> > > new ZooKeeper(" > 1000, watcher);
> > >
> > > watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> > > Assert.assertTrue("connection Established", watcher.isConnected());
> > > zk.close();
> > >   }
> > > {code}
> > > Following fix can be added to StaticHostProvider.resolveAndShuffle
> > > {code}
> > >  if(taddr.isReachable(4000 // can be some value)) {
> > >   tmpList.add(new InetSocketAddress(taddr,
> > address.getPort()));
> > > }
> > > {code}
> >
> >
> >
> > --
> > 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&focusedCommentId=15355800#comment-15355800
 ] 

Patrick Hunt commented on ZOOKEEPER-1045:
-

fwiw: notice hbase, they seem to be checking authz in their handler: 
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/security/HBaseSaslRpcServer.java

> 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-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-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&focusedCommentId=15355797#comment-15355797
 ] 

Patrick Hunt commented on ZOOKEEPER-1045:
-

I was thinking through the QuorumServer/QuorumLearner question I asked a bit 
more today, reviewing more of the patch from this perspective, and I realized 
that while we are doing authentication, we don't seem to be doing 
authorization. I don't see it mentioned in this JIRA, but I believe that we 
need to address both authn and authz with this patch. I suspect the original 
intent was to do both, even though the subject mentions authn only. The reason 
I feel so is that if we don't do authz then anyone with valid kerberos 
credentials, regardless the principal, can authenticate and operate as a member 
of the quorum. Do I have that right? From what I can tell in the code, with the 
patch applied, we are just authenticating, and not validating that the 
principal has rights to operate as a quorum member.

Here's this code in SaslServerCallbackHandler for example:

{noformat}
private void handleAuthorizeCallback(AuthorizeCallback ac) {
String authenticationID = ac.getAuthenticationID();
String authorizationID = ac.getAuthorizationID();

LOG.info("Successfully authenticated client: authenticationID=" + 
authenticationID
+ ";  authorizationID=" + authorizationID + ".");
ac.setAuthorized(true);
{noformat}

Am I reading this right or are we indeed doing authz somewhere?

> 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-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-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Marshall McMullen (JIRA)]

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

Marshall McMullen commented on ZOOKEEPER-2455:
--

Oh, neat! I was not aware of that. Thanks for filling in the gaps for me Alex.

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

Re: [jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Dan Benediktson]

Apologies for sending this on the mail list instead of through a comment on
the JIRA - I can't seem to get https://issues.apache.org/jira/ to load for
me.

Given that the goal is to open a socket, implementing an isReachable()
method which is just opening a socket with a timeout seems wasteful. It
will add unnecessary additional latency (the RTT latency for TCP handshake)
and overhead to every connection, even successful ones where the ensemble
isn't suffering due to a down host; it'll also put a little extra load on
the servers, not just clients. Would it make sense to make
ClientCnxnSocket.open() implementations apply the timeout directly?

As far as choosing the connection timeout to use, I would suggest just
using the time-sliced session timeout (I thought this was already done, but
perhaps it's only applied later in the connection handshake?) but applying
some reasonable lower bound (say, default of 1 second and overridable by a
Java system property). We actually have a fork of the ZK code which has
that minimum bound for connection timeout logic in the Java client, and I'd
be happy to prepare a patch for that part. It's pretty trivial code, but
it's important if you start using a combination of large ZK clusters and
very small session timeouts, which we have in some of our ensembles.

Thanks,
Dan

On Wed, Jun 29, 2016 at 12:27 PM, Andrew Purtell (JIRA) 
wrote:

>
> [
> https://issues.apache.org/jira/browse/ZOOKEEPER-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15355708#comment-15355708
> ]
>
> Andrew Purtell commented on ZOOKEEPER-2447:
> ---
>
> bq. An alternative would be to roll out our own equivalent of
> {{InetAddress#isReachable()}} as I scribbled below?
> Makes sense.
>
> > Zookeeper adds  good delay when one of the quorum host is not reachable
> > ---
> >
> > Key: ZOOKEEPER-2447
> > URL:
> https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> > Project: ZooKeeper
> >  Issue Type: Bug
> >Affects Versions: 3.4.6, 3.5.0
> >Reporter: Vishal Khandelwal
> >Assignee: Vishal Khandelwal
> > Fix For: 3.5.3, 3.6.0
> >
> > Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt,
> withoutFix.txt
> >
> >
> > StaticHostProvider --> resolveAndShuffle method adds all of the address
> which are valid in the quorum to the list, shuffles them and sends back to
> client connection class. If after shuffling if first node appear to be the
> one which is not reachable, Clientcnx.SendThread.run will keep on
> connecting to the failure till a timeout and the moves to a different node.
> This adds up random delay in zookeeper connection in case a host is down.
> Rather we could check if host is reachable in StaticHostProvider and ignore
> isReachable is false. Same as we do for UnknownHostException Exception.
> > This can tested using following test code by providing a valid host
> which is not reachable. for quick test comment Collections.shuffle(tmpList,
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> > {code}
> >  @Test
> >   public void test() throws Exception {
> > EventsWatcher watcher = new EventsWatcher();
> > QuorumUtil qu = new QuorumUtil(1);
> > qu.startAll();
> >
> > ZooKeeper zk =
> > new ZooKeeper(" 1000, watcher);
> >
> > watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> > Assert.assertTrue("connection Established", watcher.isConnected());
> > zk.close();
> >   }
> > {code}
> > Following fix can be added to StaticHostProvider.resolveAndShuffle
> > {code}
> >  if(taddr.isReachable(4000 // can be some value)) {
> >   tmpList.add(new InetSocketAddress(taddr,
> address.getPort()));
> > }
> > {code}
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

[jira] [Commented] (ZOOKEEPER-2454) Limit Connection Count based on User

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad commented on ZOOKEEPER-2454:


yes, you are right, this feature can work by using whole id string, need not to 
separate out the user and password.
But still I feel, not related to this jira, that there should be some mechanism 
to define what is user in zookeeper. I need this capability for ZOOKEEPER-1260. 
I created new jira ZOOKEEPER-2456 to handle there.

> Limit Connection Count based on User
> 
>
> Key: ZOOKEEPER-2454
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2454
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Botond Hejj
>Assignee: Botond Hejj
>Priority: Minor
> Attachments: ZOOKEEPER-2454-br-3-4.patch, ZOOKEEPER-2454.patch
>
>
> ZooKeeper currently can limit connection count from clients coming from the 
> same ip. It is a great feature to malfunctioning clients DOS-ing the server 
> with many requests.
> I propose additional safegurads for ZooKeeper. 
> It would be great if optionally connection count could be limited for a 
> specific user or a specific user on an ip.
> This is great in cases where ZooKeeper ensemble is shared by multiple users 
> and these users share the same client ips. This can be common in container 
> based cloud deployment where external ip of multiple clients can be the same.



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

[jira] [Updated] (ZOOKEEPER-2456) Provide API to get user from different authentication providers

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-2456:
---
Issue Type: Improvement  (was: Bug)

> Provide API to get user from different authentication providers
> ---
>
> Key: ZOOKEEPER-2456
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2456
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3
>
>
> Currently zookeeper server same field is used to store both user name and 
> password
> Provide a mechanism to separate the user and password either by adding new 
> field or by adding new API
> DETAILS:
> org.apache.zookeeper.data.Id class is used to store scheme and id.
> {code}
> public Id( String scheme, String id)
> {code}
> id field holds only user in most cases but in some cases it holds user as 
> well as password
> By default there are only four authentication provider 
> DigestAuthenticationProvider
> IPAuthenticationProvider
> SASLAuthenticationProvider
> X509AuthenticationProvider
> In code we can check if scheme is digest then {{id.split(":")\[0\]}} is user 
> otherwise id is user. This will work only if we are limited to above four 
> authentication provider
> But Custom authentication provider are very important and are very commonly 
> used. How the zookeeper code will know what is the user, is it id or 
> {{id.split(":")\[0\]}} or anything else ?
> So there is need to add new API which AuthenticationProvider providers 
> implement to define what is user.



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

[jira] [Created] (ZOOKEEPER-2456) Provide API to get user from different authentication providers

[Arshad Mohammad (JIRA)]

Arshad Mohammad created ZOOKEEPER-2456:
--

 Summary: Provide API to get user from different authentication 
providers
 Key: ZOOKEEPER-2456
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2456
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
 Fix For: 3.5.3


Currently zookeeper server same field is used to store both user name and 
password
Provide a mechanism to separate the user and password either by adding new 
field or by adding new API

DETAILS:
org.apache.zookeeper.data.Id class is used to store scheme and id.
{code}
public Id( String scheme, String id)
{code}
id field holds only user in most cases but in some cases it holds user as well 
as password
By default there are only four authentication provider 
DigestAuthenticationProvider
IPAuthenticationProvider
SASLAuthenticationProvider
X509AuthenticationProvider
In code we can check if scheme is digest then {{id.split(":")\[0\]}} is user 
otherwise id is user. This will work only if we are limited to above four 
authentication provider
But Custom authentication provider are very important and are very commonly 
used. How the zookeeper code will know what is the user, is it id or 
{{id.split(":")\[0\]}} or anything else ?
So there is need to add new API which AuthenticationProvider providers 
implement to define what is user.



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

[jira] [Commented] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-1260:
---

Please, refer to my comment at ZOOKEEPER-2287 (duplicate of this one) just to 
check if it's relevant or not.

Cheers! :)


> Audit logging in ZooKeeper servers.
> ---
>
> Key: ZOOKEEPER-1260
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
> Project: ZooKeeper
>  Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Mahadev konar
>Assignee: Arshad Mohammad
> Fix For: 3.6.0
>
>
> Lots of users have had questions on debugging which client changed what znode 
> and what updates went through a znode. We should add audit logging as in 
> Hadoop (look at Namenode Audit logging) to log which client changed what in 
> the zookeeper servers. This could just be a log4j audit logger.



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Andrew Purtell (JIRA)]

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

Andrew Purtell commented on ZOOKEEPER-2447:
---

bq. An alternative would be to roll out our own equivalent of 
{{InetAddress#isReachable()}} as I scribbled below? 
Makes sense. 

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2447:
---

Hi [~andrew.purt...@gmail.com], my concern is not the feature itself -- it is 
cool --, but the use of {{InetAddress#isReachable()}} because it seems to have 
had caused some problems in the past, that is, always returning false or true 
in spite of the real reachability, as seen below:

http://stackoverflow.com/questions/4779367/problem-with-isreachable-in-inetaddress-class

Of course, the SO threads that relate similar problems are usually old (five to 
ten years old!), so this could not be a problem anymore, but we must 
acknowledge this possible limitation. An alternative would be to roll out our 
own equivalent of {{InetAddress#isReachable()}} as I scribbled below? Wdyt?

{code}
private boolean isReachable(InetAddress address, int port, int timeout) {
if (timeout < 0)
   IllegalArgumentException("Timeout cannot be less than zero");

Socket socket = new Socket();
try {
socket.connect(new InetSocketAddress(address, port), timeout);
}
catch (IOException e) {
return false;
}
finally {
try {
socket.close();
} catch (IOException e) {
// Ignore any errors
}
}
return true;
}
}
{code}


> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Commented] (ZOOKEEPER-1078) add maven build support to ZooKeeper

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-1078:
--

+1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12814865/ZOOKEEPER-1078-05.patch
  against trunk revision 1750025.

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

+1 tests included.  The patch appears to include 27 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 passed core unit tests.

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

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

This message is automatically generated.

> add maven build support to ZooKeeper
> 
>
> Key: ZOOKEEPER-1078
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1078
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: Patrick Hunt
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1078-04.patch, ZOOKEEPER-1078-05.patch, 
> ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch
>
>
> I've taken a stab at creating a maven build for ZooKeeper. (attachment to 
> follow).



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

Success: ZOOKEEPER-1078 PreCommit Build #3255

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 445096 lines...]
 [exec]   
http://issues.apache.org/jira/secure/attachment/12814865/ZOOKEEPER-1078-05.patch
 [exec]   against trunk revision 1750025.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 27 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 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/3255//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3255//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3255//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] 067af09b92054d06926764b0937a504191a32ac2 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 20 minutes 33 seconds
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-1078
Email was triggered for: Success
Sending email for trigger: Success
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] [Resolved] (ZOOKEEPER-2287) Audit logging the zookeeper operations

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad resolved ZOOKEEPER-2287.

Resolution: Duplicate

> Audit logging the zookeeper operations
> --
>
> Key: ZOOKEEPER-2287
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2287
> Project: ZooKeeper
>  Issue Type: New Feature
>Reporter: nijel
>Assignee: Arshad Mohammad
>
> As of now Zookeeper does not support auditing the user operations
> This is a very important tracability in distributed cluster to trace the 
> operations
> We can have a separate logger and log file.
> Can start with normal node change operations.
> Please share your thoughts ? 



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

[jira] [Assigned] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad reassigned ZOOKEEPER-1260:
--

Assignee: Arshad Mohammad

> Audit logging in ZooKeeper servers.
> ---
>
> Key: ZOOKEEPER-1260
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
> Project: ZooKeeper
>  Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Mahadev konar
>Assignee: Arshad Mohammad
> Fix For: 3.6.0
>
>
> Lots of users have had questions on debugging which client changed what znode 
> and what updates went through a znode. We should add audit logging as in 
> Hadoop (look at Namenode Audit logging) to log which client changed what in 
> the zookeeper servers. This could just be a log4j audit logger.



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

[jira] [Comment Edited] (ZOOKEEPER-1078) add maven build support to ZooKeeper

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad edited comment on ZOOKEEPER-1078 at 6/29/16 6:54 PM:
-

In the previous patch some files were missed, added those missed files


was (Author: arshad.mohammad):
In the previous some files were missed, added those missed files

> add maven build support to ZooKeeper
> 
>
> Key: ZOOKEEPER-1078
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1078
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: Patrick Hunt
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1078-04.patch, ZOOKEEPER-1078-05.patch, 
> ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch
>
>
> I've taken a stab at creating a maven build for ZooKeeper. (attachment to 
> follow).



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

[jira] [Updated] (ZOOKEEPER-1078) add maven build support to ZooKeeper

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-1078:
---
Attachment: ZOOKEEPER-1078-05.patch

In the previous some files were missed, added those missed files

> add maven build support to ZooKeeper
> 
>
> Key: ZOOKEEPER-1078
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1078
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: Patrick Hunt
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1078-04.patch, ZOOKEEPER-1078-05.patch, 
> ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch
>
>
> I've taken a stab at creating a maven build for ZooKeeper. (attachment to 
> follow).



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

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[pradeep (JIRA)]

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

pradeep commented on ZOOKEEPER-2455:


Thanks All,
Could you please comment on my below queries for which I logged this bug,
- when do we get ZRUNTIMEINCONSISTENCY and what does that mean
- when we get ZRUNTIMEINCONSISTENCY, does  that also means server connection is 
closed ? I see from C bindings src that socket is closed. i wanted to confirm.
appreciate your comments on these.

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Commented] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Andrew Purtell (JIRA)]

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

Andrew Purtell commented on ZOOKEEPER-2447:
---

>From my point of view this isn't an optimization, it's a fix for a multi 
>second stall for low latency use cases. Waiting for the combined connection 
>timeouts and retries blows out low latency SLAs on our production HBase 
>clusters, for example. This behavior should be configurable. 

Agreed with the comment that the hardcoded value in the patch isn't what we 
want. It should be configurable. And I'd want to set it smaller than the 
current value. 


> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

[jira] [Issue Comment Deleted] (ZOOKEEPER-2447) Zookeeper adds good delay when one of the quorum host is not reachable

[Andrew Purtell (JIRA)]

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

Andrew Purtell updated ZOOKEEPER-2447:
--
Comment: was deleted

(was: This isn't an optimization, it's a fix for a multi second stall for low 
latency HBase use cases. Waiting for connection timeouts and retries blows out 
low latency SLAs. This behavior should be configurable. 

Agreed with the comment that the hardcoded value in the patch isn't what we 
want. It should be configurable.)

> Zookeeper adds  good delay when one of the quorum host is not reachable
> ---
>
> Key: ZOOKEEPER-2447
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2447
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2447.3.5.patch, withfix.txt, withoutFix.txt
>
>
> StaticHostProvider --> resolveAndShuffle method adds all of the address which 
> are valid in the quorum to the list, shuffles them and sends back to client 
> connection class. If after shuffling if first node appear to be the one which 
> is not reachable, Clientcnx.SendThread.run will keep on connecting to the 
> failure till a timeout and the moves to a different node. This adds up random 
> delay in zookeeper connection in case a host is down. Rather we could check 
> if host is reachable in StaticHostProvider and ignore isReachable is false. 
> Same as we do for UnknownHostException Exception.
> This can tested using following test code by providing a valid host which is 
> not reachable. for quick test comment Collections.shuffle(tmpList, 
> sourceOfRandomness); in StaticHostProvider.resolveAndShuffle
> {code}
>  @Test
>   public void test() throws Exception {
> EventsWatcher watcher = new EventsWatcher();
> QuorumUtil qu = new QuorumUtil(1);
> qu.startAll();
> 
> ZooKeeper zk =
> new ZooKeeper(" watcher);
> 
> watcher.waitForConnected(CONNECTION_TIMEOUT * 5);
> Assert.assertTrue("connection Established", watcher.isConnected());
> zk.close();
>   }
> {code}
> Following fix can be added to StaticHostProvider.resolveAndShuffle
> {code}
>  if(taddr.isReachable(4000 // can be some value)) {
>   tmpList.add(new InetSocketAddress(taddr, 
> address.getPort()));
> } 
> {code}



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

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

[Alexander Shraer (JIRA)]

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

Alexander Shraer commented on ZOOKEEPER-2152:
-

[~marshall], would you be able to review this ? You're much more familiar with 
this code than I am.

> 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.6.0
>
> Attachments: 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] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Alexander Shraer (JIRA)]

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

Alexander Shraer commented on ZOOKEEPER-2455:
-

There was a change added by Helen and Michi in ZOOKEEPER-1691, where you can 
disable standalone stack, and use a replicated stack even with 1 server.


> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Marshall McMullen (JIRA)]

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

Marshall McMullen commented on ZOOKEEPER-2455:
--

I'm confused. I didn't think you could do a dynamic reconfig from 1 server. 1 
server is what is called "standalone" mode whereas 3 or more puts you into 
"quorum" mode. And you cannot cross between these two stacks. Perhaps there was 
a change made in the reconfig code that I'm not aware of that let's you do this 
but I don't think so. [~shralex] would be able to say for certain.  Are you 
calling zoo_set_servers and giving it a new server that's not part of the 
ensemble? That would certainly cause this problem. Come to think of it, I don't 
think that there's any protection against that sort of misuse.

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Commented] (ZOOKEEPER-2320) C-client crashes when removing watcher asynchronously in "local" mode

[Abraham Fine (JIRA)]

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

Abraham Fine commented on ZOOKEEPER-2320:
-

I made changes to the build that should allow us to access the {{zk_hashtable}} 
code without making it available to end users.

[~rgs] would you mind taking a look?

> C-client crashes when removing watcher asynchronously in "local" mode
> -
>
> Key: ZOOKEEPER-2320
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2320
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: Hadriel Kaplan
>Assignee: Abraham Fine
> Attachments: ZOOKEEPER-2320.patch, ZOOKEEPER-2320.patch
>
>
> The C-client library will crash when invoking the asynchronous 
> {{zoo_aremove_watchers()}} API function with the '{{local}}' argument set to 
> 1.
> The reason is: if the local argument is 1/true, then the code does 
> '{{notify_sync_completion((struct sync_completion *)data);}}' But casting the 
> '{{data}}' variable to a {{sync_completion}} struct pointer is bogus/invalid, 
> and when it's later handles as that struct pointer it's accessing invalid 
> memory.
> As a side note: it will work ok when called _synchronously_ through 
> {{zoo_remove_watchers()}}, because that function creates a 
> {{sync_completion}} struct and passes it to the asynch 
> {{zoo_aremove_watchers()}}, but it will not work ok when the asynch function 
> is used directly for the reason stated perviously.
> Another side note: the docs state that setting the 'local' flag makes the 
> C-client remove the watcher "even if there is no server connection" - but 
> really it makes the C-client remove the watcher without notifying the server 
> at *all*, even if the connection to a server is up. (well... that's what it 
> would do if it didn't just crash instead ;)



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

RE: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Mohammad arshad]

+1 (non binding)
Built tar on windows
Generated docs
VERFICATION:
Installed 2 cluster each of 3 zk server
1)Tested following scenario for ZOOKEEPER-2139 Multi Client in a JVM (with 2 
clients from the same jvm)
i) One client connected to secure, SSL authentication enabled, cluster 
other to non-secure cluster
Both clients were doing create, delete, get data and set data  
simultaneously and continuously
ii) One client connected to kerbeors authentication enabled cluster 
other to digest authentication enabled cluster
Both clients were doing create, delete, get data and set data  
simultaneously and continuously 
2) Following Operations are verified
create node (ALL API, All node types)
delete node
set data
get data
setAcl
getAcl
multi operation
Few Four letter word commands
3) Verified all the JIRA in which I was involved, all are passed

Thanks,
Arshad

-Original Message-
From: Patrick Hunt [mailto:ph...@apache.org] 
Sent: 29 June 2016 20:47
To: DevZooKeeper
Subject: Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

Looks like that javacc dependency was added in
https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have been build 
only afaict.

Thanks for reporting this Enrico, would you mind submitting a JIRA (and perhaps 
a patch)?

Thanks,

Patrick


On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli 
wrote:

> +1 (non binding)
> Tested Majordodo (http://majordodo.org) and BlazingCache
> (http://blazingcache.org) against 3.5.2-alpha.
>
> My tests also include running Apache BookKeeper 4.4.0 using the 
> 3.5.2-alpha java client.
>
> All is fine but dependencies changed a lot, many legacy deps like 
> jline, jms and sun jmx disappeared and this is very good,
>
> but this new dependency showed up:
> net.java.dev.javacc:javacc:jar:5.0
>
> If I exclude javacc all of my tests continue to run fine, my tests 
> cover both java client and embedded single server.
> Maybe it would be useful to hide the dependency in future release but 
> it is not a showstopper for my projects.
>
>
>
> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
> > +1 tested SSL support, everything appears to be working as expected.
> >
> > On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
> >> +1. sig/xsum are valid, RAT ran clean and no other discrepancies
> noticed.
> >> I
> >> ran it through a number of manual tests (including starting a 23 
> >> server
> >> ensemble) - no issues found.
> >>
> >> Patrick
> >>
> >> On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth 
> >> 
> >> wrote:
> >>
> >> > This is a release candidate for 3.5.2-alpha. The full release 
> >> > notes
> are
> >> > available at:
> >> >
> >> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310
> 801&v
> >> > ersion=12331981
> >> >
> >> > *** Please download, test and vote by July 1st 2016, 23:59 UTC+0. 
> >> > ***
> >> >
> >> > Source files:
> >> > http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidat
> >> > e-0/
> >> >
> >> > Maven staging repo:
> >> >
> https://repository.apache.org/content/groups/staging/org/apache/zookee
> per/z
> >> > ookeeper/3.5.2-alpha/
> >> >
> >> > The tag to be voted upon:
> >> > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0
> >> > /
> >> >
> >> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >> > http://www.apache.org/dist/zookeeper/KEYS
> >> >
> >> > Should we release this candidate?
> >> >
> >> >
> >> > --Chris Nauroth
> >> >
> >> >
>

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[pradeep (JIRA)]

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

pradeep commented on ZOOKEEPER-2455:


Yes, I am doing dynamic reconfig of 1 to 2 servers.
at addition of s2, client calls zoo_set_server.then  zoo_get .
I wanted to know if I get  error code ZRUNTIMEINCONSISTENCY on calling 
zoo_get(), then connection to server is also closed ?


> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

ZooKeeper_branch35_solaris - Build # 153 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_solaris/153/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 419216 lines...]
[junit] 2016-06-29 17:26:09,250 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-06-29 17:26:09,250 [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-06-29 17:26:09,251 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-06-29 17:26:09,252 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-06-29 17:26:09,253 [myid:] - INFO  [main:ZooKeeperServer@858] 
- minSessionTimeout set to 6000
[junit] 2016-06-29 17:26:09,253 [myid:] - INFO  [main:ZooKeeperServer@867] 
- maxSessionTimeout set to 6
[junit] 2016-06-29 17:26:09,253 [myid:] - INFO  [main:ZooKeeperServer@156] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test1163136129451185468.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test1163136129451185468.junit.dir/version-2
[junit] 2016-06-29 17:26:09,254 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test1163136129451185468.junit.dir/version-2/snapshot.b
[junit] 2016-06-29 17:26:09,257 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/branch-3.5/build/test/tmp/test1163136129451185468.junit.dir/version-2/snapshot.b
[junit] 2016-06-29 17:26:09,259 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-06-29 17:26:09,259 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:35903
[junit] 2016-06-29 17:26:09,260 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:35903
[junit] 2016-06-29 17:26:09,260 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-06-29 17:26:09,260 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:35903 (no session established for client)
[junit] 2016-06-29 17:26:09,261 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-29 17:26:09,261 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@158] - SessionTrackerImpl exited loop!
[junit] 2016-06-29 17:26:09,261 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@158] - SessionTrackerImpl exited loop!
[junit] 2016-06-29 17:26:09,262 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-06-29 17:26:09,262 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-06-29 17:26:09,262 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-06-29 17:26:09,263 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-06-29 17:26:09,263 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 18146
[junit] 2016-06-29 17:26:09,263 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 22
[junit] 2016-06-29 17:26:09,263 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-06-29 17:26:09,263 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-06-29 17:26:09,342 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1221a2ee3fe closed
[junit] 2016-06-29 17:26:09,342 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1221a2ee3fe
[junit] 2016-06-29 17:26:09,342 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-06-29 17:26:09,343 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-06-29 17:26:09,343 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-06-

ZooKeeper_branch34_openjdk7 - Build # 1122 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_openjdk7/1122/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 219025 lines...]
[junit] 2016-06-29 15:33:31,754 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-29 15:33:31,754 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-29 15:33:31,754 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-29 15:33:31,755 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-06-29 15:33:31,755 [myid:] - INFO  [main:ZooKeeperServer@469] 
- shutting down
[junit] 2016-06-29 15:33:31,755 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-06-29 15:33:31,755 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-06-29 15:33:31,756 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2016-06-29 15:33:31,756 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-06-29 15:33:31,756 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2016-06-29 15:33:31,756 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-06-29 15:33:31,757 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-29 15:33:31,758 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-29 15:33:31,759 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2016-06-29 15:33:31,759 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-06-29 15:33:31,760 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-06-29 15:33:31,760 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-06-29 15:33:31,761 [myid:] - INFO  [main:ZooKeeperServer@170] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_openjdk7/branch-3.4/build/test/tmp/test8865848682076208816.junit.dir/version-2
 snapdir 
/x1/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_openjdk7/branch-3.4/build/test/tmp/test8865848682076208816.junit.dir/version-2
[junit] 2016-06-29 15:33:31,765 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-06-29 15:33:31,766 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:42508
[junit] 2016-06-29 15:33:31,767 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:42508
[junit] 2016-06-29 15:33:31,767 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-06-29 15:33:31,768 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:42508 (no session established for client)
[junit] 2016-06-29 15:33:31,768 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-29 15:33:31,770 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-06-29 15:33:31,770 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-06-29 15:33:31,770 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-06-29 15:33:31,771 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-06-29 15:33:31,771 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 26415
[junit] 2016-06-29 15:33:31,771 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-06-29 15:33:31,772 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-06-29 15:33:31,772 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2016-06-29 15:33:31,837 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x1559ccb36a2 closed
[junit] 2016-06-29 15:33:31,837 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2016-06-29 15:33:31,837 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x1559ccb36a2
[junit] 2016-06-29 15:33:31,837 [myid:] - INFO  
[N

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Patrick Hunt]

Looks like that javacc dependency was added in
https://issues.apache.org/jira/browse/ZOOKEEPER-96 and should have been
build only afaict.

Thanks for reporting this Enrico, would you mind submitting a JIRA (and
perhaps a patch)?

Thanks,

Patrick


On Wed, Jun 29, 2016 at 8:10 AM, Enrico Olivelli 
wrote:

> +1 (non binding)
> Tested Majordodo (http://majordodo.org) and BlazingCache
> (http://blazingcache.org) against 3.5.2-alpha.
>
> My tests also include running Apache BookKeeper 4.4.0 using the
> 3.5.2-alpha java client.
>
> All is fine but dependencies changed a lot, many legacy deps like
> jline, jms and sun jmx disappeared and this is very good,
>
> but this new dependency showed up:
> net.java.dev.javacc:javacc:jar:5.0
>
> If I exclude javacc all of my tests continue to run fine, my tests
> cover both java client and embedded single server.
> Maybe it would be useful to hide the dependency in future release but
> it is not a showstopper for my projects.
>
>
>
> 2016-06-28 19:52 GMT+02:00 Abraham Fine :
> > +1 tested SSL support, everything appears to be working as expected.
> >
> > On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
> >> +1. sig/xsum are valid, RAT ran clean and no other discrepancies
> noticed.
> >> I
> >> ran it through a number of manual tests (including starting a 23 server
> >> ensemble) - no issues found.
> >>
> >> Patrick
> >>
> >> On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth
> >> 
> >> wrote:
> >>
> >> > This is a release candidate for 3.5.2-alpha. The full release notes
> are
> >> > available at:
> >> >
> >> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&v
> >> > ersion=12331981
> >> >
> >> > *** Please download, test and vote by July 1st 2016, 23:59 UTC+0. ***
> >> >
> >> > Source files:
> >> > http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidate-0/
> >> >
> >> > Maven staging repo:
> >> >
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/z
> >> > ookeeper/3.5.2-alpha/
> >> >
> >> > The tag to be voted upon:
> >> > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0/
> >> >
> >> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> >> > http://www.apache.org/dist/zookeeper/KEYS
> >> >
> >> > Should we release this candidate?
> >> >
> >> >
> >> > --Chris Nauroth
> >> >
> >> >
>

[jira] [Updated] (ZOOKEEPER-96) The jute parser should get generated from the jj files instead of checking in the generated sources

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-96:
--
Fix Version/s: 3.5.0

> The jute parser should get generated from the jj files instead of checking in 
> the generated sources
> ---
>
> Key: ZOOKEEPER-96
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-96
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: Hiram Chirino
>Assignee: Thomas Koch
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-96.patch, ZOOKEEPER-96.patch
>
>




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

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-2455:
-

Comment from the list http://markmail.org/message/7jjbev3nxvg6bit2

{noformat}
I can't help you with a solution, but we are also seeing this.  We had not
made the connection to a reconfig causing this, but a quick look at some
logs indicates it may be happening to us during a reconfig as well.  That
gives us a thread to dig more-- we'll update if we find anything.
{noformat}


> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

Re: [VOTE] Apache ZooKeeper release 3.5.2-alpha candidate 0

[Enrico Olivelli]

+1 (non binding)
Tested Majordodo (http://majordodo.org) and BlazingCache
(http://blazingcache.org) against 3.5.2-alpha.

My tests also include running Apache BookKeeper 4.4.0 using the
3.5.2-alpha java client.

All is fine but dependencies changed a lot, many legacy deps like
jline, jms and sun jmx disappeared and this is very good,

but this new dependency showed up:
net.java.dev.javacc:javacc:jar:5.0

If I exclude javacc all of my tests continue to run fine, my tests
cover both java client and embedded single server.
Maybe it would be useful to hide the dependency in future release but
it is not a showstopper for my projects.



2016-06-28 19:52 GMT+02:00 Abraham Fine :
> +1 tested SSL support, everything appears to be working as expected.
>
> On Fri, Jun 24, 2016, at 03:19 PM, Patrick Hunt wrote:
>> +1. sig/xsum are valid, RAT ran clean and no other discrepancies noticed.
>> I
>> ran it through a number of manual tests (including starting a 23 server
>> ensemble) - no issues found.
>>
>> Patrick
>>
>> On Thu, Jun 23, 2016 at 10:33 PM, Chris Nauroth
>> 
>> wrote:
>>
>> > This is a release candidate for 3.5.2-alpha. The full release notes are
>> > available at:
>> >
>> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&v
>> > ersion=12331981
>> >
>> > *** Please download, test and vote by July 1st 2016, 23:59 UTC+0. ***
>> >
>> > Source files:
>> > http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidate-0/
>> >
>> > Maven staging repo:
>> > https://repository.apache.org/content/groups/staging/org/apache/zookeeper/z
>> > ookeeper/3.5.2-alpha/
>> >
>> > The tag to be voted upon:
>> > https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0/
>> >
>> > ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>> > http://www.apache.org/dist/zookeeper/KEYS
>> >
>> > Should we release this candidate?
>> >
>> >
>> > --Chris Nauroth
>> >
>> >

[jira] [Commented] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Patrick Hunt (JIRA)]

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

Patrick Hunt commented on ZOOKEEPER-2455:
-

bq. Zookeeper Client connected to Zookeeper server S1 and a new server S2 gets 
added

what does this mean? You are doing dynamic reconfig from 1 to 2 servers? Can 
you provide the operations you're running as well as the before/after 
configuration files?

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Updated] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2455:

Fix Version/s: 3.6.0
   3.5.3

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

Re: ZooKeeper 3.5.2-alpha Release Coordination

[Patrick Hunt]

That's a great point (here and Flavio's recent email). "everyone" includes
everyone, not just committers/pmc. Having additional input, reviews, and
esp testing from users is particularly valuable. If you've been asking
"when will the next release come out", well here it is (almost), please
lend your support.

Regards,

Patrick

On Tue, Jun 28, 2016 at 10:30 PM, Chris Nauroth 
wrote:

> Really, thank you to the whole community on the effort to get a release
> candidate out.
>
> Everyone, please take this opportunity to test and vote on the release
> candidate by July 1st 2016, 23:59 UTC+0.  This is a long-awaited release,
> so let's do everything we can to ensure it gets shipped.
>
> --Chris Nauroth
>
>
>
>
> On 6/28/16, 1:19 AM, "Flavio Junqueira"  wrote:
>
> >Agreed, thank you, Chris, for getting the release candidate out.
> >
> >Thank you for volunteering to be the release manager for the 3.5.3
> >release, Pat.
> >
> >-Flavio
> >
> >
> >> On 25 Jun 2016, at 00:16, Patrick Hunt  wrote:
> >>
> >> Kudos on getting the RC out Chris. Re progress I've updated my
> >>dashboard to
> >> provide some insight. In particular checkout "ZooKeeper 3.5.1+ Blocker
> >>or
> >> Critical" created/resolved chart. Seems to show we've been doing
> >>reasonably
> >> in burning down the blocker/critical issues. We're currently down to 8
> >> blockers for 3.5.3 (12 when you sent out your original email):
> >>
> >>
> >>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=1232768
> >>8
> >>
> >> I believe we should continue to focus on these (critical/blockers) over
> >> adding any new features for the remainder of 3.5 development. I'd be
> >>happy
> >> to drive the 3.5.3-alpha release towards that goal as RM.
> >>
> >> Patrick
> >>
> >> On Thu, Jun 23, 2016 at 1:03 PM, Chris Nauroth
> >>
> >> wrote:
> >>
> >>> We are close!  There are currently 4 issues remaining targeted to
> >>>3.5.2.
> >>>
> >>> ZOOKEEPER-2247 was mentioned as desired for 3.5.2.  Flavio and Rakesh,
> >>>do
> >>> you think this can get closed down and committed soon?  If so, I will
> >>>hold
> >>> up the release.
> >>>
> >>> ZOOKEEPER-1460 has a fix committed to branch-3.5, but it remains open
> >>>to
> >>> track a back-port to branch-3.4.  At this point, I will close the
> >>>issue,
> >>> targeted only to 3.5.2, and create a separate issue targeted to 3.4.9
> >>>for
> >>> specifically tracking that back-port.
> >>>
> >>> ZOOKEEPER-2366 and ZOOKEEPER-2380 are reviewed and +1'd already.  I
> >>>will
> >>> commit them before creating the release candidate.
> >>>
> >>> --Chris Nauroth
> >>>
> >>>
> >>>
> >>>
> >>> On 6/21/16, 12:05 PM, "Chris Nauroth" 
> wrote:
> >>>
>  I'd like to propose a deadline of 12 noon Thursday, 6/23 PST.  If
> anyone
>  needs a later deadline, please let me know.
> 
>  --Chris Nauroth
> 
> 
> 
> 
>  On 6/21/16, 10:08 AM, "Patrick Hunt"  wrote:
> 
> > 1045 is currently only against 3.4. Once we have that solid I would
> >think
> > we'd port it to 3.5 and include it in a future release (3.5.3?)
> >
> > Patrick
> >
> > On Tue, Jun 21, 2016 at 10:02 AM, Flavio Junqueira 
> > wrote:
> >
> >> ZK-2366 and ZK-2247 should be ready for commit shortly. We aren't
> >> including ZK-1045 in 3.5.2, right?
> >>
> >> -Flavio
> >>
> >>> On 21 Jun 2016, at 17:43, Patrick Hunt  wrote:
> >>>
> >>> Can we set a deadline/date for the release? It's fine to have
> >> blockers
> >>> while we're still in alpha. We should cut a release for folks that
> >> want
> >> to
> >>> get access to the latest.
> >>>
> >>> Patrick
> >>>
> >>> On Mon, Jun 20, 2016 at 5:17 PM, Chris Nauroth
> >>  >>>
> >>> wrote:
> >>>
>  I am about to take the plunge and start deferring all JIRA issues
>  currently targeted to 3.5.2 into 3.5.3.  I will likely start doing
> >> this
>  sometime around 12 noon PST on Tuesday, 6/21.  Nearly every issue
> in
> >> this
>  list will be deferred:
> 
>  https://s.apache.org/Y0jP
> 
>  I know we have a few blocker and critical issues still under
> active
> >> code
>  review that we want for 3.5.2.  I'll keep those in.
> 
>  --Chris Nauroth
> 
> 
> 
> 
>  On 5/12/16, 2:44 PM, "Patrick Hunt"  wrote:
> 
> > Hi Chris. +1 on that. I believe it's imperative that we get
> >> 3.5.2-alpha
> > out
> > and continue to drive towards stability. I'll work with Michael
> >to
> >> get
> > 2405
> > finalized.
> >
> > Patrick
> >
> > On Tue, May 10, 2016 at 2:54 PM, Chris Nauroth <
> >> cnaur...@hortonworks.com>
> > wrote:
> >
> >> When we last discussed a ZooKeeper 3.5.2-alpha release
> >>candidate,
> >> we
>

[jira] [Updated] (ZOOKEEPER-2455) unexpected server response ZRUNTIMEINCONSISTENCY

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2455:

Affects Version/s: 3.5.1

> unexpected server response ZRUNTIMEINCONSISTENCY
> 
>
> Key: ZOOKEEPER-2455
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2455
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: pradeep
> Fix For: 3.5.3, 3.6.0
>
>
> Hi Folks,
> I am hitting an error in my C client code and below are the set of operations 
> I perform:
>   1.  Zookeeper Client connected to Zookeeper server S1 and a new server S2 
> gets added.
>   2.  monitor zookeeper server config at the client and on change of server 
> config, call zoo_set_server
> from the client
>   3.  client can issue operations like zoo_get just after the call to 
> zoo_set_servers
>   4.  I can see that the zookeeper thread logs connect to the new server just 
> after the zoo_get
> call
> 2016-04-11 03:46:50,655:1207(0xf26ffb40):ZOO_INFO@check_events@2345: 
> initiated connection
> to server [128.0.0.5:61728]
> 2016-04-11 03:46:50,658:1207(0xf26ffb40):ZOO_INFO@check_events@2397: session 
> establishment
> complete on server [128.0.0.5:61728], sessionId=0x401852c000c, negotiated 
> timeout=2
>   5.  Some times I find errors like below:
> 2016-04-11 
> 03:46:50,662:1207(0xf26ffb40):ZOO_ERROR@handle_socket_error_msg@2923: Socket 
> [128.0.0.5:61728]
> zk retcode=-2, errno=115(Operation now in progress): unexpected server 
> response: expected
> 0x570b82fa, but received 0x570b82f9
>   1.
> zoo_get returns (-2) indicating that 
> ZRUNTIMEINCONSISTENCY
> What is the issue here? should I be retry the operation zoo_get operation? Or 
> should I wait
> for the zoo_set_server to complete (like wait for the connection 
> establishment notification)
> Thanks,



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

[jira] [Commented] (ZOOKEEPER-2454) Limit Connection Count based on User

[Botond Hejj (JIRA)]

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

Botond Hejj commented on ZOOKEEPER-2454:


Good point.

We could call this than limiting by id. All the auth plugins have id field 
already. I understand that id might be not equal to user all the time and maybe 
some auth plugins are not based on user at all.

In digest you point out that user is different than the id which is true but 
actually a user maps to a single id so using id instead of user leads to the 
same result.

> Limit Connection Count based on User
> 
>
> Key: ZOOKEEPER-2454
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2454
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Botond Hejj
>Assignee: Botond Hejj
>Priority: Minor
> Attachments: ZOOKEEPER-2454-br-3-4.patch, ZOOKEEPER-2454.patch
>
>
> ZooKeeper currently can limit connection count from clients coming from the 
> same ip. It is a great feature to malfunctioning clients DOS-ing the server 
> with many requests.
> I propose additional safegurads for ZooKeeper. 
> It would be great if optionally connection count could be limited for a 
> specific user or a specific user on an ip.
> This is great in cases where ZooKeeper ensemble is shared by multiple users 
> and these users share the same client ips. This can be common in container 
> based cloud deployment where external ip of multiple clients can be the same.



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

[jira] [Commented] (ZOOKEEPER-2454) Limit Connection Count based on User

[Botond Hejj (JIRA)]

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

Botond Hejj commented on ZOOKEEPER-2454:


I've created a review on the board:
https://reviews.apache.org/r/49373/

Thanks for the comments. Let's move the conversation there.

Ip limiting also doesn't work on NettyServerCnxn and I've based this change on 
that.
I agree it would be great to port all this to Netty but I haven't spent time on 
that.

> Limit Connection Count based on User
> 
>
> Key: ZOOKEEPER-2454
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2454
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Botond Hejj
>Assignee: Botond Hejj
>Priority: Minor
> Attachments: ZOOKEEPER-2454-br-3-4.patch, ZOOKEEPER-2454.patch
>
>
> ZooKeeper currently can limit connection count from clients coming from the 
> same ip. It is a great feature to malfunctioning clients DOS-ing the server 
> with many requests.
> I propose additional safegurads for ZooKeeper. 
> It would be great if optionally connection count could be limited for a 
> specific user or a specific user on an ip.
> This is great in cases where ZooKeeper ensemble is shared by multiple users 
> and these users share the same client ips. This can be common in container 
> based cloud deployment where external ip of multiple clients can be the same.



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

[jira] [Commented] (ZOOKEEPER-2454) Limit Connection Count based on User

[Botond Hejj (JIRA)]

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

Botond Hejj commented on ZOOKEEPER-2454:


The user and user/ip based limiting is very similar to the ip based limiting. 
It is a global limit. Similar in ip based limiting you can't specify limit per 
ip. 

I will add documentation. How should that be done? In this jira description? 
Shall I attach separate docs or a patch to some existing docs?

> Limit Connection Count based on User
> 
>
> Key: ZOOKEEPER-2454
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2454
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Botond Hejj
>Assignee: Botond Hejj
>Priority: Minor
> Attachments: ZOOKEEPER-2454-br-3-4.patch, ZOOKEEPER-2454.patch
>
>
> ZooKeeper currently can limit connection count from clients coming from the 
> same ip. It is a great feature to malfunctioning clients DOS-ing the server 
> with many requests.
> I propose additional safegurads for ZooKeeper. 
> It would be great if optionally connection count could be limited for a 
> specific user or a specific user on an ip.
> This is great in cases where ZooKeeper ensemble is shared by multiple users 
> and these users share the same client ips. This can be common in container 
> based cloud deployment where external ip of multiple clients can be the same.



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

Vote on release 3.5.2-alpha candidate 0

[Flavio Junqueira]

I want to reinforce the message and encourage everyone, not only committers and 
PMC members, to test and vote on the release candidate. I can't stress enough 
how important it is for the quality of the release that multiple folks test 
with their systems to make sure that the RC is good.

If you don't know how to start, here are a few hints:

- Download the sources and build it
- Try to use it with whatever application you care about
- Check licenses and headers (the RAT tool is ideal for that)
- Check digests and signature
- Check miscellaneous things like README

Please take some time to have a look, test it, and vote.

Thanks,
-Flavio

> On 24 Jun 2016, at 06:33, Chris Nauroth  wrote:
> 
> This is a release candidate for 3.5.2-alpha. The full release notes are
> available at:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&v
> ersion=12331981
> 
> *** Please download, test and vote by July 1st 2016, 23:59 UTC+0. ***
> 
> Source files:
> http://people.apache.org/~cnauroth/zookeeper-3.5.2-alpha-candidate-0/
> 
> Maven staging repo:
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/z
> ookeeper/3.5.2-alpha/
> 
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.2-rc0/
> 
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
> 
> Should we release this candidate?
> 
> 
> --Chris Nauroth
> 

[jira] [Commented] (ZOOKEEPER-2454) Limit Connection Count based on User

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad commented on ZOOKEEPER-2454:


Before proceeding ahead, first we should clearly define what is user in 
zookeeper through API.
If this solution is only for kerberos authentication then not required 
otherwise it is must. 

org.apache.zookeeper.data.Id class is used to store scheme and id.
{code}
public Id(
String scheme,
String id)
{code}
id field holds only user in most cases but in some cases it holds user as well 
as password

By default there are only four authentication provider 
DigestAuthenticationProvider
IPAuthenticationProvider
SASLAuthenticationProvider
X509AuthenticationProvider
In code we can check if scheme is digest then {{id.split(":")\[0\]}} is user 
otherwise id is user. This will work only if we are limited to above four 
authentication provider

But Custom authentication provider are very important and are very commonly 
used. How the zookeeper code will know what is the user, is it id or  
{{id.split(":")\[0\]}} or anything else ?
So there is need to define to add new API which AuthenticationProvider 
providers implement to define what is user.
For example DigestAuthenticationProvider will implement as
{code}
@Override
public String getUserName(String id) {
return id.split(":")[0];
}
{code}
SASLAuthenticationProvider will implement as 
{code}
@Override
public String getUserName(String id) {
return id;
}
{code}
CustomAuthenticationProvider will implement as 
{code}
@Override
public String getUserName(String id) {
// Some logic and then return user
return user;
}
{code}
This is how zookeeper code will get the user for any authentication scheme
{code}
Id id=Get id from org.apache.zookeeper.server.Request.authInfo
AuthenticationProvider authProvider = 
ProviderRegistry.getProvider(id.getScheme());
String user=authProvider.getUserName(id.getId());
{code}

> Limit Connection Count based on User
> 
>
> Key: ZOOKEEPER-2454
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2454
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Botond Hejj
>Assignee: Botond Hejj
>Priority: Minor
> Attachments: ZOOKEEPER-2454-br-3-4.patch, ZOOKEEPER-2454.patch
>
>
> ZooKeeper currently can limit connection count from clients coming from the 
> same ip. It is a great feature to malfunctioning clients DOS-ing the server 
> with many requests.
> I propose additional safegurads for ZooKeeper. 
> It would be great if optionally connection count could be limited for a 
> specific user or a specific user on an ip.
> This is great in cases where ZooKeeper ensemble is shared by multiple users 
> and these users share the same client ips. This can be common in container 
> based cloud deployment where external ip of multiple clients can be the same.



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

ZooKeeper_branch35_openjdk7 - Build # 134 - Failure

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 439321 lines...]
[junit] 2016-06-29 10:10:27,816 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:14159
[junit] 2016-06-29 10:10:27,811 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port14159,name1=Connections,name2=127.0.0.1,name3=0x108ca481e54]
[junit] 2016-06-29 10:10:27,824 [myid:] - INFO  [main:ZooKeeperServer@498] 
- shutting down
[junit] 2016-06-29 10:10:27,828 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-06-29 10:10:27,828 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-06-29 10:10:27,828 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-06-29 10:10:27,828 [myid:] - INFO  [ProcessThread(sid:0 
cport:14159)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-06-29 10:10:27,828 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-06-29 10:10:27,829 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-06-29 10:10:27,829 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port14159,name1=InMemoryDataTree]
[junit] 2016-06-29 10:10:27,829 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port14159]
[junit] 2016-06-29 10:10:27,830 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 14159
[junit] 2016-06-29 10:10:27,830 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-29 10:10:27,837 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 5111 at start it was 5111
[junit] 2016-06-29 10:10:27,837 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-06-29 10:10:27,837 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
471.188 sec, Thread: 2, Class: org.apache.zookeeper.test.NettyNettySuiteTest
[junit] 2016-06-29 10:10:28,054 [myid:127.0.0.1:14039] - INFO  
[main-SendThread(127.0.0.1:14039):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:14039. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-06-29 10:10:28,056 [myid:] - INFO  [New I/O boss 
#9438:ClientCnxnSocketNetty$1@127] - future isn't success, cause: {}
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[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-06-29 10:10:28,056 [myid:] - WARN  [New I/O boss 
#9438:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id: 
0xd9cb76db] EXCEPTION: java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:14039
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(Abst

Success: ZOOKEEPER-2320 PreCommit Build #3254

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 441534 lines...]
 [exec]   against trunk revision 1750025.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 4 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 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/3254//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3254//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3254//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] 
 [exec] Remote error: (0)null
 [exec] 59d2ea8bd4b0aa6747cccbca11e1fbe34e49a6f3 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 20 minutes 58 seconds
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-2320
Email was triggered for: Success
Sending email for trigger: Success
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-2320) C-client crashes when removing watcher asynchronously in "local" mode

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-2320:
--

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

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

+1 tests included.  The patch appears to include 4 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 passed core unit tests.

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

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

This message is automatically generated.

> C-client crashes when removing watcher asynchronously in "local" mode
> -
>
> Key: ZOOKEEPER-2320
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2320
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: Hadriel Kaplan
>Assignee: Abraham Fine
> Attachments: ZOOKEEPER-2320.patch, ZOOKEEPER-2320.patch
>
>
> The C-client library will crash when invoking the asynchronous 
> {{zoo_aremove_watchers()}} API function with the '{{local}}' argument set to 
> 1.
> The reason is: if the local argument is 1/true, then the code does 
> '{{notify_sync_completion((struct sync_completion *)data);}}' But casting the 
> '{{data}}' variable to a {{sync_completion}} struct pointer is bogus/invalid, 
> and when it's later handles as that struct pointer it's accessing invalid 
> memory.
> As a side note: it will work ok when called _synchronously_ through 
> {{zoo_remove_watchers()}}, because that function creates a 
> {{sync_completion}} struct and passes it to the asynch 
> {{zoo_aremove_watchers()}}, but it will not work ok when the asynch function 
> is used directly for the reason stated perviously.
> Another side note: the docs state that setting the 'local' flag makes the 
> C-client remove the watcher "even if there is no server connection" - but 
> really it makes the C-client remove the watcher without notifying the server 
> at *all*, even if the connection to a server is up. (well... that's what it 
> would do if it didn't just crash instead ;)



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

ZooKeeper_branch35_jdk7 - Build # 568 - Failure

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 436218 lines...]
[junit] 2016-06-29 08:57:01,368 [myid:127.0.0.1:14042] - INFO  
[main-SendThread(127.0.0.1:14042):ClientCnxn$SendThread@1231] - channel for 
sessionid 0x308ca021c6b is lost, closing socket connection and attempting 
reconnect
[junit] 2016-06-29 08:57:01,882 [myid:] - INFO  [ProcessThread(sid:0 
cport:14159)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x108ca04e785
[junit] 2016-06-29 08:57:01,882 [myid:] - INFO  [New I/O worker 
#14359:ClientCnxnSocketNetty$ZKClientHandler@384] - channel is disconnected: 
[id: 0x3f7f6693, /127.0.0.1:46351 :> 127.0.0.1/127.0.0.1:14159]
[junit] 2016-06-29 08:57:01,883 [myid:] - INFO  [New I/O worker 
#14359:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2016-06-29 08:57:01,882 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port14159,name1=Connections,name2=127.0.0.1,name3=0x108ca04e785]
[junit] 2016-06-29 08:57:01,882 [myid:] - WARN  [New I/O worker 
#14456:NettyServerCnxnFactory$CnxnChannelHandler@142] - Exception caught [id: 
0x73d0e7a6, /127.0.0.1:46351 :> /127.0.0.1:14159] EXCEPTION: 
java.nio.channels.ClosedChannelException
[junit] java.nio.channels.ClosedChannelException
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:433)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:373)
[junit] at 
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:81)
[junit] at 
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
[junit] at 
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
[junit] at 
org.jboss.netty.channel.SimpleChannelHandler.closeRequested(SimpleChannelHandler.java:334)
[junit] at 
org.jboss.netty.channel.SimpleChannelHandler.handleDownstream(SimpleChannelHandler.java:260)
[junit] at 
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
[junit] at 
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
[junit] at org.jboss.netty.channel.Channels.close(Channels.java:812)
[junit] at 
org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:206)
[junit] at 
org.apache.zookeeper.server.NettyServerCnxn.close(NettyServerCnxn.java:111)
[junit] at 
org.apache.zookeeper.server.NettyServerCnxn.sendBuffer(NettyServerCnxn.java:215)
[junit] at 
org.apache.zookeeper.server.NettyServerCnxn.sendCloseSession(NettyServerCnxn.java:441)
[junit] at 
org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:459)
[junit] at 
org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:182)
[junit] at 
org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:113)
[junit] 2016-06-29 08:57:01,883 [myid:] - INFO  
[main:ClientCnxnSocketNetty@208] - channel is told closing
[junit] 2016-06-29 08:57:01,883 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x108ca04e785 closed
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 172592
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1778
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:14159
[junit] 2016-06-29 08:57:01,884 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x108ca04e785
[junit] 2016-06-29 08:57:01,887 [myid:] - INFO  [main:ZooKeeperServer@498] 
- shutting down
[junit] 2016-06-29 08:57:01,887 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-06-29 08:57:01,887 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-06-29 08:57:01,887 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-06-29 08:57:01,888 [myid:] - INFO  [Process

[jira] [Updated] (ZOOKEEPER-2320) C-client crashes when removing watcher asynchronously in "local" mode

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2320:

Attachment: ZOOKEEPER-2320.patch

> C-client crashes when removing watcher asynchronously in "local" mode
> -
>
> Key: ZOOKEEPER-2320
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2320
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.5.1
>Reporter: Hadriel Kaplan
>Assignee: Abraham Fine
> Attachments: ZOOKEEPER-2320.patch, ZOOKEEPER-2320.patch
>
>
> The C-client library will crash when invoking the asynchronous 
> {{zoo_aremove_watchers()}} API function with the '{{local}}' argument set to 
> 1.
> The reason is: if the local argument is 1/true, then the code does 
> '{{notify_sync_completion((struct sync_completion *)data);}}' But casting the 
> '{{data}}' variable to a {{sync_completion}} struct pointer is bogus/invalid, 
> and when it's later handles as that struct pointer it's accessing invalid 
> memory.
> As a side note: it will work ok when called _synchronously_ through 
> {{zoo_remove_watchers()}}, because that function creates a 
> {{sync_completion}} struct and passes it to the asynch 
> {{zoo_aremove_watchers()}}, but it will not work ok when the asynch function 
> is used directly for the reason stated perviously.
> Another side note: the docs state that setting the 'local' flag makes the 
> C-client remove the watcher "even if there is no server connection" - but 
> really it makes the C-client remove the watcher without notifying the server 
> at *all*, even if the connection to a server is up. (well... that's what it 
> would do if it didn't just crash instead ;)



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

Re: Review Request 49125: ZOOKEEPER-2320

[Abraham Fine]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/49125/
---

(Updated June 29, 2016, 8:49 a.m.)


Review request for zookeeper.


Bugs: ZOOKEEPER-2320
https://issues.apache.org/jira/browse/ZOOKEEPER-2320


Repository: zookeeper-git


Description
---

C-client crashes when removing watcher asynchronously in "local" mode


Diffs (updated)
-

  src/c/Makefile.am adaf0c8 
  src/c/src/zk_adaptor.h 2039fb3 
  src/c/src/zk_hashtable.h 5227e07 
  src/c/src/zk_hashtable.c 8f87a96 
  src/c/src/zk_hashtable/zk_hashtable.h PRE-CREATION 
  src/c/src/zk_hashtable/zk_hashtable.c PRE-CREATION 
  src/c/src/zookeeper.c 7549d48 
  src/c/tests/TestClient.cc 3fbcb1b 

Diff: https://reviews.apache.org/r/49125/diff/


Testing
---


Thanks,

Abraham Fine

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

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 420558 lines...]
[junit] 2016-06-29 08:24:23,499 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-06-29 08:24:23,500 [myid:] - INFO  [main:ClientBase@466] - 
STARTING server
[junit] 2016-06-29 08:24:23,500 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-06-29 08:24:23,500 [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-06-29 08:24:23,501 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-06-29 08:24:23,502 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-06-29 08:24:23,502 [myid:] - INFO  [main:ZooKeeperServer@858] 
- minSessionTimeout set to 6000
[junit] 2016-06-29 08:24:23,502 [myid:] - INFO  [main:ZooKeeperServer@867] 
- maxSessionTimeout set to 6
[junit] 2016-06-29 08:24:23,503 [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/test2228748623917311703.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2228748623917311703.junit.dir/version-2
[junit] 2016-06-29 08:24:23,503 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2228748623917311703.junit.dir/version-2/snapshot.b
[junit] 2016-06-29 08:24:23,505 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test2228748623917311703.junit.dir/version-2/snapshot.b
[junit] 2016-06-29 08:24:23,507 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-06-29 08:24:23,507 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:43781
[junit] 2016-06-29 08:24:23,508 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:43781
[junit] 2016-06-29 08:24:23,508 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-06-29 08:24:23,509 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:43781 (no session established for client)
[junit] 2016-06-29 08:24:23,511 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-06-29 08:24:23,512 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-06-29 08:24:23,512 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-06-29 08:24:23,512 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-06-29 08:24:23,513 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-06-29 08:24:23,513 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17718
[junit] 2016-06-29 08:24:23,513 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-06-29 08:24:23,513 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-06-29 08:24:23,513 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-06-29 08:24:23,592 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x122183ee4bb closed
[junit] 2016-06-29 08:24:23,592 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x122183ee4bb
[junit] 2016-06-29 08:24:23,592 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-06-29 08:24:23,593 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-06-29 08:24:23,593 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-06-29 08:24:23,593 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@4

[jira] [Commented] (ZOOKEEPER-1078) add maven build support to ZooKeeper

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira commented on ZOOKEEPER-1078:
-

It is great to see progress on this, thank you [~arshad.mohammad]!

> add maven build support to ZooKeeper
> 
>
> Key: ZOOKEEPER-1078
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1078
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: Patrick Hunt
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1078-04.patch, ZOOKEEPER-1078.patch, 
> ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch
>
>
> I've taken a stab at creating a maven build for ZooKeeper. (attachment to 
> follow).



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