date:20160917

[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.

2016-09-17 Thread Edward Ribeiro (JIRA)


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

Edward Ribeiro commented on ZOOKEEPER-2439:
---

Hi [~hanm]!

{quote}
Should we check ACL in FinalRequestProcessor?
{quote}

I hope so! :) I considered this solution too, but sidetracked because I am 
unsure about transactional guarantees, particularly the _*sync request to 
disk*_ performed by {{SyncRequestProcessor}}.

Note: by the way, my stab at a solution (just a sketch, really) most probably 
breaks on parallel unit test running due to the use of static mutable fields.

{quote}
note we already check ACL in FinalRequestProcessor (example) for some ops, but 
not all, not sure why.
{quote}

The *non state changing* operations (exists, getData, getChildren, etc) follow 
a slightly different, more straightforward, path down the processing pipeline 
while transactional, *state changing*, operations (setData, delete, setACL, 
etc) perform a series of extra operations, as expected. Therefore, it looks 
like {{FinalRequestProcessor}} is currently checking the ACL permissions for 
non transactional check/read operations (even tough _exists()_ operation is 
lacking ACL check, a bug, imho) while the transactional operations are handled 
by {{PrepRequestProcessor.pRequest2Txn}} nowadays.


> The order of asynchronous setACL is not correct.
> 
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
>  Labels: acl
> Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper 
> server is always ordered, as both synchronous and asynchronous commands are 
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a 
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous 
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls 
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL 
> between (1) and (2), the synchronous case works correctly but the 
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but 
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test 
> sometimes fails as well but only rarely.



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

[jira] [Created] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

2016-09-17 Thread Edward Ribeiro (JIRA)

Edward Ribeiro created ZOOKEEPER-2591:
-

 Summary: The deletion of Container znode doesn't check ACL delete 
permission
 Key: ZOOKEEPER-2591
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
 Project: ZooKeeper
  Issue Type: Bug
  Components: security, server
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro


Container nodes check the ACL before creation, but the deletion doesn't check  
the ACL rights. The code below succeeds even tough we removed ACL access 
permissions for "/a".

{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
ArrayList list = new ArrayList<>();
list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/a", list, -1);

zk.delete("/a", -1);
{code}



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

[jira] [Updated] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

2016-09-17 Thread Edward Ribeiro (JIRA)


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

Edward Ribeiro updated ZOOKEEPER-2590:
--
Description: 
As hinted  
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
 even if a parent znode path has restricted READ access it's possible to issue 
an exists() operation on any child znode of that given path.

 For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it 
removes ACL rights to "/":

{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));

zk.setACL("/", acls, -1);

Stat r = zk.exists("/a", false);
{code}

Also, in the above example, what if the removed READ access for "/a"? Should we 
allow a call to exists("/a") to succeed even if it returns the znode metadata 
info?

  was:
As hinted  
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
 even if a parent znode path has restricted READ access it's possible to issue 
an exists() operation on any child znode of that given path.

 For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it 
removes ACL rights to "/":

{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));

zk.setACL("/", acls, -1);

Stat r = zk.exists("/a", false);
{code}


> setACL doesn't affect exists() operation
> 
>
> Key: ZOOKEEPER-2590
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>  Labels: acl, security
>
> As hinted  
> [here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
>  even if a parent znode path has restricted READ access it's possible to 
> issue an exists() operation on any child znode of that given path.
>  For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough 
> it removes ACL rights to "/":
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
> ArrayList acls = new ArrayList<>();
> acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", acls, -1);
> Stat r = zk.exists("/a", false);
> {code}
> Also, in the above example, what if the removed READ access for "/a"? Should 
> we allow a call to exists("/a") to succeed even if it returns the znode 
> metadata info?



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

[jira] [Assigned] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

2016-09-17 Thread Edward Ribeiro (JIRA)


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

Edward Ribeiro reassigned ZOOKEEPER-2590:
-

Assignee: Edward Ribeiro

> setACL doesn't affect exists() operation
> 
>
> Key: ZOOKEEPER-2590
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>  Labels: acl, security
>
> As hinted  
> [here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
>  even if a parent znode path has restricted READ access it's possible to 
> issue an exists() operation on any child znode of that given path.
>  For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough 
> it removes ACL rights to "/":
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
> ArrayList acls = new ArrayList<>();
> acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", acls, -1);
> Stat r = zk.exists("/a", false);
> {code}



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

[jira] [Created] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

2016-09-17 Thread Edward Ribeiro (JIRA)

Edward Ribeiro created ZOOKEEPER-2590:
-

 Summary: setACL doesn't affect exists() operation
 Key: ZOOKEEPER-2590
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Edward Ribeiro


As hinted  
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
 even if a parent znode path has restricted READ access it's possible to issue 
an exists() operation on any child znode of that given path.

 For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it 
removes ACL rights to "/":

{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));

zk.setACL("/", acls, -1);

Stat r = zk.exists("/a", false);
{code}



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

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

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 446682 lines...]
[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-09-17 20:02:43,011 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x1007b6bd39c closed
[junit] 2016-09-17 20:02:43,011 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1007b6bd39c
[junit] 2016-09-17 20:02:43,011 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 97688
[junit] 2016-09-17 20:02:43,012 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 466
[junit] 2016-09-17 20:02:43,012 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-09-17 20:02:43,012 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-09-17 20:02:43,012 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-09-17 20:02:43,012 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:19545
[junit] 2016-09-17 20:02:43,018 [myid:] - INFO  [main:ZooKeeperServer@529] 
- shutting down
[junit] 2016-09-17 20:02:43,018 [myid:] - ERROR [main:ZooKeeperServer@501] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-09-17 20:02:43,018 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-09-17 20:02:43,018 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-09-17 20:02:43,019 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-09-17 20:02:43,019 [myid:] - INFO  [ProcessThread(sid:0 
cport:19545)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-09-17 20:02:43,019 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-09-17 20:02:43,019 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-09-17 20:02:43,020 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port19545,name1=InMemoryDataTree]
[junit] 2016-09-17 20:02:43,020 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port19545]
[junit] 2016-09-17 20:02:43,021 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 19545
[junit] 2016-09-17 20:02:43,021 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-09-17 20:02:43,042 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 1378 at start it was 1382
[junit] 2016-09-17 20:02:43,042 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-09-17 20:02:43,042 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
428.113 sec, Thread: 4, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-09-17 20:02:43,621 [myid:127.0.0.1:19422] - INFO  
[main-SendThread(127.0.0.1:19422):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:19422. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 20:02:43,622 [myid:127.0.0.1:19422] - WARN  
[main-SendThread(127.0.0.1:19422):ClientCnxn$SendThread@1235] - Session 
0x1007b69011d for server 127.0.0.1/127.0.0.1:19422, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at

[jira] [Commented] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory

2016-09-17 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on ZOOKEEPER-2547:
--

+1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12829065/ZOOKEEPER-2547-02.patch
  against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.

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

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

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

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

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

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

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

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

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

This message is automatically generated.

> IP ACL is not working with NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-2547
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2547
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2547-01.patch, ZOOKEEPER-2547-02.patch
>
>
> IP based ACL is not working with NettyServerCnxnFactory.
> Scenario:
> 1) Configure serverCnxnFactory= 
> org.apache.zookeeper.server.NettyServerCnxnFactory and start ZooKeeper server
> 2) Create a znode  "/n" with ACL(ZooDefs.Perms.ALL, new Id("ip", 
> "127.0.0.1/8")
> 3) Create child node /n/n1. Child node creation fails.
> But the same above scenario works with NIOServerCnxnFactory



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

Success: ZOOKEEPER-2547 PreCommit Build #3440

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 467367 lines...]
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 3 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 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/3440//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3440//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3440//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] 98c6370f80a059820396f0041795ab1f7014bbd0 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] mv: 
‘/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess’ 
and 
‘/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess’ 
are the same file

BUILD SUCCESSFUL
Total time: 17 minutes 43 seconds
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2547
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Success
Sending email for trigger: Success
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



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

[jira] [Updated] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory

2016-09-17 Thread Arshad Mohammad (JIRA)


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

Arshad Mohammad updated ZOOKEEPER-2547:
---
Attachment: ZOOKEEPER-2547-02.patch

Thanks [~eribeiro] for the clarification.
Added negative scenario test in the new patch.

> IP ACL is not working with NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-2547
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2547
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2547-01.patch, ZOOKEEPER-2547-02.patch
>
>
> IP based ACL is not working with NettyServerCnxnFactory.
> Scenario:
> 1) Configure serverCnxnFactory= 
> org.apache.zookeeper.server.NettyServerCnxnFactory and start ZooKeeper server
> 2) Create a znode  "/n" with ACL(ZooDefs.Perms.ALL, new Id("ip", 
> "127.0.0.1/8")
> 3) Create child node /n/n1. Child node creation fails.
> But the same above scenario works with NIOServerCnxnFactory



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

[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.

2016-09-17 Thread Michael Han (JIRA)


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

Michael Han commented on ZOOKEEPER-2439:


Should we check ACL in FinalRequestProcessor? Because of total ordering 
guarantee, proposal on changing ACL should be committed when 
FinalRequestProcessor is processing the create node proposal - note we already 
check ACL in FinalRequestProcessor 
([example|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L320])
 for some ops, but not all, not sure why. 

> The order of asynchronous setACL is not correct.
> 
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
>  Labels: acl
> Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper 
> server is always ordered, as both synchronous and asynchronous commands are 
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a 
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous 
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls 
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL 
> between (1) and (2), the synchronous case works correctly but the 
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but 
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test 
> sometimes fails as well but only rarely.



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

[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored

2016-09-17 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on ZOOKEEPER-2517:
--

+1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12829061/ZOOKEEPER-2517-04.patch
  against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.

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

+1 tests included.  The patch appears to include 5 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/3439//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3439//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3439//console

This message is automatically generated.

> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch, 
> ZOOKEEPER-2517-03.patch, ZOOKEEPER-2517-04.patch, ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
>   clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
>   ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the 
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
>   clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
>   )
> );{code}



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

Success: ZOOKEEPER-2517 PreCommit Build #3439

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 455288 lines...]
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 5 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/3439//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3439//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3439//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] mv: 
‘/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess’ 
and 
‘/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess’ 
are the same file
 [exec] 133f86d96d6d8b38e5a5fe15de3dc15f7cf48031 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 

BUILD SUCCESSFUL
Total time: 17 minutes 37 seconds
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2517
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Success
Sending email for trigger: Success
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



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

[jira] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored

2016-09-17 Thread Arshad Mohammad (JIRA)


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

Arshad Mohammad updated ZOOKEEPER-2517:
---
Attachment: ZOOKEEPER-2517-04.patch

In the new patch, throwing {{IOException}} in case invalid {{jute.maxbuffer}} 
is configured.

> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch, 
> ZOOKEEPER-2517-03.patch, ZOOKEEPER-2517-04.patch, ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
>   clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
>   ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the 
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
>   clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
>   )
> );{code}



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

[jira] [Commented] (ZOOKEEPER-2532) zkCli throwing nullpointerException instead it should provide help when invalid input is entered

2016-09-17 Thread Michael Han (JIRA)


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

Michael Han commented on ZOOKEEPER-2532:


It is weird indeed. Tried trigger QA bot a couple of times through 
cancel/submit not working either.
Not sure if it works to trigger the job directly in Jenkins.

> zkCli throwing nullpointerException instead it should provide help when 
> invalid input is entered
> 
>
> Key: ZOOKEEPER-2532
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2532
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.5.1, 3.5.2
>Reporter: Rakesh Kumar Singh
>Assignee: Rakesh Kumar Singh
>Priority: Minor
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2532.patch
>
>
> 1. a) Connect to zookeeper using zkCli
>  b) just input space and then hit enter
> 2. a) Connect to zookeeper using zkCli and hit enter it will come as 
> connected 
>  b) just input space and then hit enter
> Console log is as below:-
> [zk: localhost:2181(CONNECTING) 0] 2016-08-25 16:54:48,143 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxnSocketNetty$ZKClientPipelineFactory@363]
>  - SSL handler added for channel: null
> 2016-08-25 16:54:48,175 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@980] - Socket 
> connection established, initiating session, client: /0:0:0:0:0:0:0:1:44592, 
> server: localhost/0:0:0:0:0:0:0:1:2181
> 2016-08-25 16:54:48,178 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxnSocketNetty$1@146] - channel is 
> connected: [id: 0xd03f4226, /0:0:0:0:0:0:0:1:44592 => 
> localhost/0:0:0:0:0:0:0:1:2181]
> 2016-08-25 16:54:48,288 [myid:] - INFO  [New I/O worker 
> #1:ClientCnxn$SendThread@1400] - Session establishment complete on server 
> localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x101a00305cc0005, negotiated 
> timeout = 3
> WATCHER::
> WatchedEvent state:SyncConnected type:None path:null
>
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.zookeeper.ZooKeeperMain$MyCommandOptions.getArgArray(ZooKeeperMain.java:171)
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:613)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:577)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:360)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:320)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:280)
> 
> After connection is established, input space and hit enter
> [zk: localhost:2181(CONNECTING) 0] 2016-08-25 16:56:22,445 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxnSocketNetty$ZKClientPipelineFactory@363]
>  - SSL handler added for channel: null
> 2016-08-25 16:56:22,481 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxn$SendThread@980] - Socket 
> connection established, initiating session, client: /0:0:0:0:0:0:0:1:44594, 
> server: localhost/0:0:0:0:0:0:0:1:2181
> 2016-08-25 16:56:22,484 [myid:] - INFO  
> [main-SendThread(localhost:2181):ClientCnxnSocketNetty$1@146] - channel is 
> connected: [id: 0xe6d3a461, /0:0:0:0:0:0:0:1:44594 => 
> localhost/0:0:0:0:0:0:0:1:2181]
> 2016-08-25 16:56:22,597 [myid:] - INFO  [New I/O worker 
> #1:ClientCnxn$SendThread@1400] - Session establishment complete on server 
> localhost/0:0:0:0:0:0:0:1:2181, sessionid = 0x101a00305cc0007, negotiated 
> timeout = 3
> WATCHER::
> WatchedEvent state:SyncConnected type:None path:null
> [zk: localhost:2181(CONNECTED) 0]  
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.zookeeper.ZooKeeperMain$MyCommandOptions.getArgArray(ZooKeeperMain.java:171)
>   at 
> org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:613)
>   at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:577)
>   at 
> org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:360)
>   at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:320)
>   at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:280)



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

[jira] [Comment Edited] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

2016-09-17 Thread Rakesh R (JIRA)


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

Rakesh R edited comment on ZOOKEEPER-2383 at 9/17/16 5:29 PM:
--

Thanks [~fpj] for the comments. 

bq. In NettyServerCnxn, it looks like we are only updating the code for 4lws. 
Don't we have to also update it here:

I think, I have handled this case and the following condition present in 
[ZOOKEEPER-2383-br-3-4.patch|https://issues.apache.org/jira/secure/attachment/12821043/ZOOKEEPER-2383-br-3-4.patch].
 Am I missing any other case apart from the below line of code.
{code}
@@ -735,7 +735,7 @@
 bb.flip();
 
 ZooKeeperServer zks = this.zkServer;
-if (zks == null) {
+if (zks == null || !zks.isRunning()) {
 throw new IOException("ZK down");
 }
 if (initialized) {
{code}

bq. but it never exists as the client keeps trying to connect. It sounds like 
some thread is hanging and not letting the test framework exit.
Without patch it fails at {{simplezks.waitForStartupInvocation(10)}}. On the 
other side {{SimpleZooKeeperServer#startup}} thread is waiting at 
startupDelayLatch.await() and this is causing an indefinite wait. How about 
adding the countdown logic in finally so that it will proceed:
{code}
try {
Assert.assertFalse(
"Should fail to create zk client session as server is not 
fully started",
simplezks.waitForSessionCreation(10));
} finally {
LOG.info(
"Decrements the count of the latch, so that server will 
proceed with startup");
startupDelayLatch.countDown();
}
{code}

bq. This sentence doesn't make much sense to me: Since zk server is not started 
createsession method to be invoked
I will modify this to "Should fail to create zk client session as server is not 
fully started"

bq. Please reduce the test case timeout to no longer than 30s.
Agreed.

FYI, apart from the above, I had fixed [Michael's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15409673=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15409673]
 and [Raul's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15408826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408826]
 in trunk patch, need to rebase branch-3-4 patch to incorporate these comments.


was (Author: rakeshr):
Thanks [~fpj] for the comments. 

bq. In NettyServerCnxn, it looks like we are only updating the code for 4lws. 
Don't we have to also update it here:

I think, I have handled this case and the following condition present in 
[ZOOKEEPER-2383-br-3-4.patch|https://issues.apache.org/jira/secure/attachment/12821043/ZOOKEEPER-2383-br-3-4.patch].
 Am I missing any other case apart from the below line of code.
{code}
@@ -735,7 +735,7 @@
 bb.flip();
 
 ZooKeeperServer zks = this.zkServer;
-if (zks == null) {
+if (zks == null || !zks.isRunning()) {
 throw new IOException("ZK down");
 }
 if (initialized) {
{code}

bq. but it never exists as the client keeps trying to connect. It sounds like 
some thread is hanging and not letting the test framework exit.
Without patch it fails at {{simplezks.waitForStartupInvocation(10)}}. On the 
other side {{SimpleZooKeeperServer#startup}} thread is waiting at 
startupDelayLatch.await() and this is causing an indefinite wait. How about 
adding a timed out like below:
{code}
startupDelayLatch.await(15, TimeUnit.SECONDS);
{code}

bq. This sentence doesn't make much sense to me: Since zk server is not started 
createsession method to be invoked
I will modify this to "Should fail to create zk client session as server is not 
fully started"

bq. Please reduce the test case timeout to no longer than 30s.
Agreed.

FYI, apart from the above, I had fixed [Michael's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15409673=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15409673]
 and [Raul's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15408826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408826]
 in trunk patch, need to rebase branch-3-4 patch to incorporate these comments.

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>

[jira] [Comment Edited] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

2016-09-17 Thread Rakesh R (JIRA)


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

Rakesh R edited comment on ZOOKEEPER-2383 at 9/17/16 5:21 PM:
--

Thanks [~fpj] for the comments. 

bq. In NettyServerCnxn, it looks like we are only updating the code for 4lws. 
Don't we have to also update it here:

I think, I have handled this case and the following condition present in 
[ZOOKEEPER-2383-br-3-4.patch|https://issues.apache.org/jira/secure/attachment/12821043/ZOOKEEPER-2383-br-3-4.patch].
 Am I missing any other case apart from the below line of code.
{code}
@@ -735,7 +735,7 @@
 bb.flip();
 
 ZooKeeperServer zks = this.zkServer;
-if (zks == null) {
+if (zks == null || !zks.isRunning()) {
 throw new IOException("ZK down");
 }
 if (initialized) {
{code}

bq. but it never exists as the client keeps trying to connect. It sounds like 
some thread is hanging and not letting the test framework exit.
Without patch it fails at {{simplezks.waitForStartupInvocation(10)}}. On the 
other side {{SimpleZooKeeperServer#startup}} thread is waiting at 
startupDelayLatch.await() and this is causing an indefinite wait. How about 
adding a timed out like below:
{code}
startupDelayLatch.await(15, TimeUnit.SECONDS);
{code}

bq. This sentence doesn't make much sense to me: Since zk server is not started 
createsession method to be invoked
I will modify this to "Should fail to create zk client session as server is not 
fully started"

bq. Please reduce the test case timeout to no longer than 30s.
Agreed.

FYI, apart from the above, I had fixed [Michael's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15409673=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15409673]
 and [Raul's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15408826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408826]
 in trunk patch, need to rebase branch-3-4 patch to incorporate these comments.


was (Author: rakeshr):
Thanks [~fpj] for the comments. 

bq. In NettyServerCnxn, it looks like we are only updating the code for 4lws. 
Don't we have to also update it here:

I think, I have handled this case and the following condition present in 
[ZOOKEEPER-2383-br-3-4.patch|https://issues.apache.org/jira/secure/attachment/12821043/ZOOKEEPER-2383-br-3-4.patch].
 Am I missing any other case apart from the below line of code.
{code}
@@ -735,7 +735,7 @@
 bb.flip();
 
 ZooKeeperServer zks = this.zkServer;
-if (zks == null) {
+if (zks == null || !zks.isRunning()) {
 throw new IOException("ZK down");
 }
 if (initialized) {
{code}

bq. but it never exists as the client keeps trying to connect. It sounds like 
some thread is hanging and not letting the test framework exit.
Without patch it fails at {{simplezks.waitForStartupInvocation(10)}}. On the 
other side {{SimpleZooKeeperServer#startup}} thread is waiting at 
startupDelayLatch.await() and this is causing an indefinite wait. How about 
adding a timed out like below:
{code}
startupDelayLatch.await(15, TimeUnit.SECONDS);
{code}

bq. This sentence doesn't make much sense to me: Since zk server is not started 
createsession method to be invoked
I will modify this to "Failed to establish ZooKeeper client connection"

bq. Please reduce the test case timeout to no longer than 30s.
Agreed.

FYI, apart from the above, I had fixed [Michael's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15409673=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15409673]
 and [Raul's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15408826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408826]
 in trunk patch, need to rebase branch-3-4 patch to incorporate these comments.

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java, 
> ZOOKEEPER-2383-br-3-4.patch, ZOOKEEPER-2383.patch, ZOOKEEPER-2383.patch, 
> ZOOKEEPER-2383.patch, release-3.4.8-extra-logging.patch, 
>

[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

2016-09-17 Thread Rakesh R (JIRA)


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

Rakesh R commented on ZOOKEEPER-2383:
-

Thanks [~fpj] for the comments. 

bq. In NettyServerCnxn, it looks like we are only updating the code for 4lws. 
Don't we have to also update it here:

I think, I have handled this case and the following condition present in 
[ZOOKEEPER-2383-br-3-4.patch|https://issues.apache.org/jira/secure/attachment/12821043/ZOOKEEPER-2383-br-3-4.patch].
 Am I missing any other case apart from the below line of code.
{code}
@@ -735,7 +735,7 @@
 bb.flip();
 
 ZooKeeperServer zks = this.zkServer;
-if (zks == null) {
+if (zks == null || !zks.isRunning()) {
 throw new IOException("ZK down");
 }
 if (initialized) {
{code}

bq. but it never exists as the client keeps trying to connect. It sounds like 
some thread is hanging and not letting the test framework exit.
Without patch it fails at {{simplezks.waitForStartupInvocation(10)}}. On the 
other side {{SimpleZooKeeperServer#startup}} thread is waiting at 
startupDelayLatch.await() and this is causing an indefinite wait. How about 
adding a timed out like below:
{code}
startupDelayLatch.await(15, TimeUnit.SECONDS);
{code}

bq. This sentence doesn't make much sense to me: Since zk server is not started 
createsession method to be invoked
I will modify this to "Failed to establish ZooKeeper client connection"

bq. Please reduce the test case timeout to no longer than 30s.
Agreed.

FYI, apart from the above, I had fixed [Michael's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15409673=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15409673]
 and [Raul's 
comment|https://issues.apache.org/jira/browse/ZOOKEEPER-2383?focusedCommentId=15408826=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15408826]
 in trunk patch, need to rebase branch-3-4 patch to incorporate these comments.

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java, 
> ZOOKEEPER-2383-br-3-4.patch, ZOOKEEPER-2383.patch, ZOOKEEPER-2383.patch, 
> ZOOKEEPER-2383.patch, release-3.4.8-extra-logging.patch, 
> zk-3.4.8-MBeanRegistry.log, zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8 
> (SOLR-8724) I ran into test failures where attempts to create a node in a 
> newly started standalone ZooKeeperServer were failing because of an assertion 
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then 
> registers itself in JMX, but if a connection comes in before the server's JMX 
> registration happens, registration of the connection will fail because it 
> trips the assertion that (effectively) its parent (the server) has already 
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this 
> issue with ZK 3.4.6. 



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

[GitHub] zookeeper pull request #81: Update Watcher.java

2016-09-17 Thread Rumo-Arf

GitHub user Rumo-Arf opened a pull request:

https://github.com/apache/zookeeper/pull/81

Update Watcher.java

Switch case clause, may wrote like this. Isn't it?

The other switch case clause wrote like that so...

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Rumo-Arf/zookeeper patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/zookeeper/pull/81.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #81


commit 835f00135e406148ab4da947422cf4d76b37e51c
Author: Rumo 
Date:   2016-09-17T14:49:00Z

Update Watcher.java

Switch case, may wrote like this.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

2016-09-17 Thread Flavio Junqueira (JIRA)


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

Flavio Junqueira commented on ZOOKEEPER-2383:
-

[~rakesh_r] I have checked the 3.4 patch. In {{NettyServerCnxn}}, it looks like 
we are only updating the code for 4lws. Don't we have to also update it here:

{noformat}
if (zks == null) {
throw new IOException("ZK down");
}
{noformat}

This is in {{NettyServerCnxn.receiveMessage}.

About the test case:

# I ran it with and without the changes. With the changes, it works fine. 
Without the changes, it hangs forever. I noticed in the logs that it gets:

{noformat}
java.lang.AssertionError: Since zk server is not started createsession method 
to be invoked
{noformat}

but it never exists as the client keeps trying to connect. It sounds like some 
thread is hanging and not letting the test framework exit.

# This sentence doesn't make much sense to me: {{Since zk server is not started 
createsession method to be invoked}}
# Please reduce the test case timeout to no longer than 30s.

> Startup race in ZooKeeperServer
> ---
>
> Key: ZOOKEEPER-2383
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2383
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: jmx, server
>Affects Versions: 3.4.8
>Reporter: Steve Rowe
>Assignee: Rakesh R
>Priority: Blocker
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: TestZkStandaloneJMXRegistrationRaceConcurrent.java, 
> ZOOKEEPER-2383-br-3-4.patch, ZOOKEEPER-2383.patch, ZOOKEEPER-2383.patch, 
> ZOOKEEPER-2383.patch, release-3.4.8-extra-logging.patch, 
> zk-3.4.8-MBeanRegistry.log, zk-3.4.8-NPE.log
>
>
> In attempting to upgrade Solr's ZooKeeper dependency from 3.4.6 to 3.4.8 
> (SOLR-8724) I ran into test failures where attempts to create a node in a 
> newly started standalone ZooKeeperServer were failing because of an assertion 
> in MBeanRegistry.
> ZooKeeperServer.startup() first sets up its request processor chain then 
> registers itself in JMX, but if a connection comes in before the server's JMX 
> registration happens, registration of the connection will fail because it 
> trips the assertion that (effectively) its parent (the server) has already 
> registered itself.
> {code:java|title=ZooKeeperServer.java}
> public synchronized void startup() {
> if (sessionTracker == null) {
> createSessionTracker();
> }
> startSessionTracker();
> setupRequestProcessors();
> registerJMX();
> state = State.RUNNING;
> notifyAll();
> }
> {code}
> {code:java|title=MBeanRegistry.java}
> public void register(ZKMBeanInfo bean, ZKMBeanInfo parent)
> throws JMException
> {
> assert bean != null;
> String path = null;
> if (parent != null) {
> path = mapBean2Path.get(parent);
> assert path != null;
> }
> {code}
> This problem appears to be new with ZK 3.4.8 - AFAIK Solr never had this 
> issue with ZK 3.4.6. 



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

ZooKeeper-trunk-jdk8 - Build # 752 - Still Failing

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 440038 lines...]
[junit] 2016-09-17 12:01:42,185 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 27624
[junit] 2016-09-17 12:01:42,185 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-09-17 12:01:42,189 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 4829 at start it was 4829
[junit] 2016-09-17 12:01:42,190 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-09-17 12:01:42,190 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
627.2 sec, Thread: 7, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-09-17 12:01:42,268 [myid:127.0.0.1:27507] - INFO  
[main-SendThread(127.0.0.1:27507):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27507. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 12:01:42,269 [myid:127.0.0.1:27507] - WARN  
[main-SendThread(127.0.0.1:27507):ClientCnxn$SendThread@1235] - Session 
0x300e1d6bd31 for server 127.0.0.1/127.0.0.1:27507, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-09-17 12:03:24,417 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 129093
[junit] 2016-09-17 12:03:24,418 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 55
[junit] 2016-09-17 12:03:24,418 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testManyChildWatchersAutoReset
[junit] 2016-09-17 12:03:24,419 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-09-17 12:03:24,420 [myid:] - INFO  [ProcessThread(sid:0 
cport:24690)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x100e1cf0129
[junit] 2016-09-17 12:03:24,469 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x100e1cf0129 closed
[junit] 2016-09-17 12:03:24,469 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x100e1cf0129
[junit] 2016-09-17 12:03:24,469 [myid:] - INFO  [ProcessThread(sid:0 
cport:24690)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x100e1cf01290001
[junit] 2016-09-17 12:03:24,469 [myid:] - INFO  
[NIOWorkerThread-19:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port24690,name1=Connections,name2=127.0.0.1,name3=0x100e1cf0129]
[junit] 2016-09-17 12:03:24,471 [myid:] - INFO  
[NIOWorkerThread-19:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:55666 which had sessionid 0x100e1cf0129
[junit] 2016-09-17 12:03:24,493 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x100e1cf01290001 closed
[junit] 2016-09-17 12:03:24,493 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x100e1cf01290001
[junit] 2016-09-17 12:03:24,494 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-09-17 12:03:24,493 [myid:] - INFO  
[NIOWorkerThread-2:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port24690,name1=Connections,name2=127.0.0.1,name3=0x100e1cf01290001]
[junit] 2016-09-17 12:03:24,495 [myid:] - INFO  
[NIOWorkerThread-2:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:55671 which had sessionid 0x100e1cf01290001
[junit] 2016-09-17 12:03:24,495 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-09-17 12:03:24,496 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:24690:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2016-09-17 12:03:24,496 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-09-17 12:03:24,501 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-09-17 12:03:24,503 [myid:] - INFO

ZooKeeper_branch35_openjdk7 - Build # 233 - Failure

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 473851 lines...]
[junit] 2016-09-17 10:41:02,316 [myid:127.0.0.1:13963] - INFO  
[main-SendThread(127.0.0.1:13963):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:13963. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 10:41:02,316 [myid:127.0.0.1:13963] - WARN  
[main-SendThread(127.0.0.1:13963):ClientCnxn$SendThread@1235] - Session 
0x100e1851a7b for server 127.0.0.1/127.0.0.1:13963, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-09-17 10:41:03,228 [myid:127.0.0.1:13969] - INFO  
[main-SendThread(127.0.0.1:13969):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:13969. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 10:41:03,228 [myid:127.0.0.1:13969] - WARN  
[main-SendThread(127.0.0.1:13969):ClientCnxn$SendThread@1235] - Session 
0x300e1851a7a for server 127.0.0.1/127.0.0.1:13969, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-09-17 10:41:03,256 [myid:127.0.0.1:13987] - INFO  
[main-SendThread(127.0.0.1:13987):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:13987. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 10:41:03,257 [myid:127.0.0.1:13987] - INFO  
[main-SendThread(127.0.0.1:13987):ClientCnxn$SendThread@948] - Socket 
connection established, initiating session, client: /127.0.0.1:55010, server: 
127.0.0.1/127.0.0.1:13987
[junit] 2016-09-17 10:41:03,257 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:/127.0.0.1:13987:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:55010
[junit] 2016-09-17 10:41:03,257 [myid:] - WARN  
[NIOWorkerThread-29:NIOServerCnxn@369] - Exception causing close of session 
0x0: ZooKeeperServer not running
[junit] 2016-09-17 10:41:03,257 [myid:] - INFO  
[NIOWorkerThread-29:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:55010 (no session established for client)
[junit] 2016-09-17 10:41:03,258 [myid:127.0.0.1:13987] - INFO  
[main-SendThread(127.0.0.1:13987):ClientCnxn$SendThread@1231] - Unable to read 
additional data from server sessionid 0x0, likely server has closed socket, 
closing socket connection and attempting reconnect
[junit] 2016-09-17 10:41:03,802 [myid:127.0.0.1:13963] - INFO  
[main-SendThread(127.0.0.1:13963):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:13963. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 10:41:03,803 [myid:127.0.0.1:13963] - WARN  
[main-SendThread(127.0.0.1:13963):ClientCnxn$SendThread@1235] - Session 
0x100e1851a7b for server 127.0.0.1/127.0.0.1:13963, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-09-17 10:41:04,106 [myid:127.0.0.1:13966] - INFO  
[main-SendThread(127.0.0.1:13966):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:13966. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-17 10:41:04,107 [myid:127.0.0.1:13966] - WARN  
[main-SendThread(127.0.0.1:13966):ClientCnxn$SendThread@1235] - Session 
0x200e1851be6 for server 127.0.0.1/127.0.0.1:13966, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused

Re: 2.4.9 ZooKeeperServer uninitialized variable

2016-09-17 Thread Flavio Junqueira

Actually, it seems related but not quite the same issue, it refers to JMX 
registration, which is what ZK-2026 was about. I need to have a more careful 
look into ZK-2383.

-Flavio
 
> On 17 Sep 2016, at 02:59, Rakesh Radhakrishnan  wrote:
> 
> Thanks for the analysis and discussions.
> 
> There is already jira raised to address this case, ZOOKEEPER-2383. Its in
> patch available state now and waiting for more reviews & +1 votes to push
> it upstream.
> Appreciate help in resolving this and include this in 3.4.10 version.
> 
> Rakesh
> 
> On Sat, Sep 17, 2016 at 3:36 AM, Flavio Junqueira  wrote:
> 
>> I've been able to repro this. There is a race in
>> NIOServerCnxnFactory.startup. We start the cnxn factory before we call
>> startup on the zookeeper server. If we call createSession from the cnxn
>> factory before we start the server, then we get the NPE. An easy way to
>> repro is to add a sleep here:
>> 
>> @Override
>>public void startup(ZooKeeperServer zks) throws IOException,
>>InterruptedException {
>>start();
>>setZooKeeperServer(zks);
>>zks.startdata();
>>Thread.sleep(3000);
>>zks.startup();
>>}
>> 
>> Afaict, this does't cause any problem on the server, and the client will
>> simply try again. It is ugly, though, we should fix it for the next release.
>> 
>> I believe the issue that introduced it is ZOOKEEPER-2026.
>> 
>> -Flavio
>> 
>> 
>>> On 16 Sep 2016, at 20:02, Flavio Junqueira  wrote:
>>> 
>>> Thanks for reporting this issue. Could you create a jira for this,
>> please?
>>> 
>>> Also, small observation, but I think you meant to say 3.4.9 in the
>> subject.
>>> 
>>> -Flavio
>>> 
 On 16 Sep 2016, at 05:38, Colin Dupee  wrote:
 
 It appears sessionTracker was intended to have a value of null, but
>> simply has no value assigned (@109).  This results in a failure to compare
>> to null in startup (@415), and an object never being created.  While the
>> server seems to be at least partially functional, it does produce an NPE on
>> startup:
 2016-09-16 00:12:31,285 [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181]
>> WARN  org.apache.zookeeper.server.NIOServerCnxnFactory  - Ignoring
>> unexpected runtime exception
 java.lang.NullPointerException
   at org.apache.zookeeper.server.
>> ZooKeeperServer.createSession(ZooKeeperServer.java:597)
   at org.apache.zookeeper.server.ZooKeeperServer.
>> processConnectRequest(ZooKeeperServer.java:930)
   at org.apache.zookeeper.server.NIOServerCnxn.
>> readConnectRequest(NIOServerCnxn.java:418)
   at org.apache.zookeeper.server.
>> NIOServerCnxn.readPayload(NIOServerCnxn.java:198)
   at org.apache.zookeeper.server.NIOServerCnxn.doIO(
>> NIOServerCnxn.java:244)
   at org.apache.zookeeper.server.NIOServerCnxnFactory.run(
>> NIOServerCnxnFactory.java:203)
   at java.lang.Thread.run(Thread.java:745)
 
 Colin DUPÉE
 Computer Scientist
 3dMD LLC
 
 +1 770.612.8002, ext. 22 (Atlanta Office)
 cdu...@3dmd.com 
 3dMD.com 
 
 Follow 3dMD on: linkedin.com/company/3dmd > company/3dmd>
 Find 3dMD on: facebook.com/3dMDcommunity > 3dMDcommunity>
 Follow 3dMD on: twitter.com/3dMD 
 
 Confidentiality Notice: This e-mail transmission, including any
>> attachments, contains confidential information and is protected by law as a
>> legally privileged document and copyright work. Its content is for the sole
>> use of the intended recipient(s) and should not be disclosed, given or
>> copied to anyone other than the person(s) named or referenced above. Any
>> unauthorized review, retransmission, dissemination, or other use of this
>> information by other than the intended recipient is prohibited. If you are
>> not the intended recipient and have received this email in error, please
>> contact the sender by reply e-mail and destroy all copies of the original
>> message.
>>> 
>> 
>>

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

2016-09-17 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 9253 lines...]
[junit] 2016-09-17 07:37:54,728 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWriterSuccess
[junit] 2016-09-17 07:37:54,728 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWriterSuccess
[junit] 2016-09-17 07:37:54,728 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWriterSuccess
[junit] 2016-09-17 07:37:54,730 [myid:] - INFO  [main:ZKTestCase$1@55] - 
STARTING testOutputStreamFailure
[junit] 2016-09-17 07:37:54,731 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD 
testOutputStreamFailure
[junit] 2016-09-17 07:37:54,735 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 10250
[junit] 2016-09-17 07:37:54,735 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 4
[junit] 2016-09-17 07:37:54,736 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testOutputStreamFailure
[junit] 2016-09-17 07:37:54,736 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testOutputStreamFailure
[junit] 2016-09-17 07:37:54,736 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testOutputStreamFailure
[junit] 2016-09-17 07:37:54,738 [myid:] - INFO  [main:ZKTestCase$1@55] - 
STARTING testWriterFailure
[junit] 2016-09-17 07:37:54,738 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD 
testWriterFailure
[junit] 2016-09-17 07:37:54,743 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 10250
[junit] 2016-09-17 07:37:54,744 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 4
[junit] 2016-09-17 07:37:54,744 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWriterFailure
[junit] 2016-09-17 07:37:54,745 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWriterFailure
[junit] 2016-09-17 07:37:54,745 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWriterFailure
[junit] 2016-09-17 07:37:54,745 [myid:] - INFO  [main:ZKTestCase$1@55] - 
STARTING testOutputStreamFailureIOException
[junit] 2016-09-17 07:37:54,746 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD 
testOutputStreamFailureIOException
[junit] 2016-09-17 07:37:54,750 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 10588
[junit] 2016-09-17 07:37:54,751 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 4
[junit] 2016-09-17 07:37:54,751 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testOutputStreamFailureIOException
[junit] 2016-09-17 07:37:54,751 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testOutputStreamFailureIOException
[junit] 2016-09-17 07:37:54,752 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testOutputStreamFailureIOException
[junit] 2016-09-17 07:37:54,752 [myid:] - INFO  [main:ZKTestCase$1@55] - 
STARTING testWriterFailureError
[junit] 2016-09-17 07:37:54,752 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD 
testWriterFailureError
[junit] 2016-09-17 07:37:54,807 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 10588
[junit] 2016-09-17 07:37:54,808 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 4
[junit] 2016-09-17 07:37:54,809 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWriterFailureError
[junit] 2016-09-17 07:37:54,809 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWriterFailureError
[junit] 2016-09-17 07:37:54,809 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWriterFailureError
[junit] 2016-09-17 07:37:54,810 [myid:] - INFO  [main:ZKTestCase$1@55] - 
STARTING testOutputStreamSuccessNE
[junit] 2016-09-17 07:37:54,810 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD 
testOutputStreamSuccessNE
[junit] 2016-09-17 07:37:54,863 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 10588
[junit] 2016-09-17 07:37:54,863 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 4
[junit] 2016-09-17 07:37:54,864 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testOutputStreamSuccessNE
[junit] 2016-09-17 07:37:54,864 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testOutputStreamSuccessNE
[junit] 2016-09-17 07:37:54,864 [myid:] - INFO  [main:ZKTestCase$1@60] -

[jira] [Created] (ZOOKEEPER-2589) Not able to access znode if IP ACL is set on a znode when zookeeper started in ssl mode

2016-09-17 Thread Rakesh Kumar Singh (JIRA)

Rakesh Kumar Singh created ZOOKEEPER-2589:
-

 Summary: Not able to access znode if  IP ACL is set on a znode 
when zookeeper started in ssl mode
 Key: ZOOKEEPER-2589
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2589
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.5.1
Reporter: Rakesh Kumar Singh


Not able to access znode if  IP ACL is set on a znode when zookeeper started in 
ssl mode.

Steps to reproduce:-
1. Start zookeeper in SSL (standalone) mode
2. Create a znode
3. set ip ACL and connect the zkCli and try to access, it does not allow.

[zk: localhost:2181(CONNECTED) 3] setAcl /test ip:127.0.0.1:crdwa
[zk: localhost:2181(CONNECTED) 5] quit

>> start the zkCli with 127.0.0.1 and trying access the znode
[zk: 127.0.0.1:2181(CONNECTED) 0] get -s /test
Authentication is not valid : /test
[zk: 127.0.0.1:2181(CONNECTED) 1] getAcl /test
'ip,'127.0.0.1
: cdrwa
[zk: 127.0.0.1:2181(CONNECTED) 2] get /test
Authentication is not valid : /test




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

[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.

[jira] [Created] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission

[jira] [Updated] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

[jira] [Assigned] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

[jira] [Created] (ZOOKEEPER-2590) setACL doesn't affect exists() operation

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

[jira] [Commented] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory

Success: ZOOKEEPER-2547 PreCommit Build #3440

[jira] [Updated] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory

[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.

[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored

Success: ZOOKEEPER-2517 PreCommit Build #3439

[jira] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored

[jira] [Commented] (ZOOKEEPER-2532) zkCli throwing nullpointerException instead it should provide help when invalid input is entered

[jira] [Comment Edited] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

[jira] [Comment Edited] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

[GitHub] zookeeper pull request #81: Update Watcher.java

[jira] [Commented] (ZOOKEEPER-2383) Startup race in ZooKeeperServer

ZooKeeper-trunk-jdk8 - Build # 752 - Still Failing

ZooKeeper_branch35_openjdk7 - Build # 233 - Failure

Re: 2.4.9 ZooKeeperServer uninitialized variable

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

[jira] [Created] (ZOOKEEPER-2589) Not able to access znode if IP ACL is set on a znode when zookeeper started in ssl mode

24 matches

Site Navigation

Mail list logo

Footer information