[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad commented on ZOOKEEPER-1971:


ZOOKEEPER-1971-03.patch addressed all review comments, also did some more 
changes to improve the overall patch.

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad commented on ZOOKEEPER-1971:


There is no test failure. One test case skipped but not because of this patch

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

Re: 2.4.9 ZooKeeperServer uninitialized variable

[Rakesh Radhakrishnan]

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_branch34 - Build # 1657 - Still Failing

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 224410 lines...]
[junit] 2016-09-17 00:13:02,457 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-09-17 00:13:02,457 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-09-17 00:13:02,457 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-09-17 00:13:02,457 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-09-17 00:13:02,458 [myid:] - INFO  
[main:SyncRequestProcessor@208] - Shutting down
[junit] 2016-09-17 00:13:02,458 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-09-17 00:13:02,458 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@186] - SyncRequestProcessor exited!
[junit] 2016-09-17 00:13:02,459 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-09-17 00:13:02,460 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-09-17 00:13:02,460 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-09-17 00:13:02,461 [myid:] - INFO  [main:ClientBase@445] - 
STARTING server
[junit] 2016-09-17 00:13:02,462 [myid:] - INFO  [main:ClientBase@366] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-09-17 00:13:02,462 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-09-17 00:13:02,462 [myid:] - INFO  [main:ClientBase@341] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-09-17 00:13:02,463 [myid:] - INFO  [main:ZooKeeperServer@173] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/build/test/tmp/test1139994955301335677.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34/build/test/tmp/test1139994955301335677.junit.dir/version-2
[junit] 2016-09-17 00:13:02,468 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-09-17 00:13:02,468 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-09-17 00:13:02,469 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:37491
[junit] 2016-09-17 00:13:02,469 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:37491
[junit] 2016-09-17 00:13:02,470 [myid:] - INFO  
[Thread-5:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-09-17 00:13:02,470 [myid:] - INFO  
[Thread-5:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:37491 (no session established for client)
[junit] 2016-09-17 00:13:02,470 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-09-17 00:13:02,472 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-09-17 00:13:02,472 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-09-17 00:13:02,473 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-09-17 00:13:02,473 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-09-17 00:13:02,473 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 31168
[junit] 2016-09-17 00:13:02,473 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-09-17 00:13:02,474 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-09-17 00:13:02,474 [myid:] - INFO  [main:ClientBase@522] - 
tearDown starting
[junit] 2016-09-17 00:13:02,538 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x157357d3bc5 closed
[junit] 2016-09-17 00:13:02,538 [myid:] - INFO  [main:ClientBase@492] - 
STOPPING server
[junit] 2016-09-17 00:13:02,538 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x157357d3bc5
[junit] 2016-09-17 00:13:02,538 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-09-17 00:13:02,539 [myid:] - 

Re: 2.4.9 ZooKeeperServer uninitialized variable

[Flavio Junqueira]

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 
>> 
>> Find 3dMD on: facebook.com/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.
> 

[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-1971:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12828907/ZOOKEEPER-1971-03.patch
  against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.

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

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

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

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

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

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

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

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

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

This message is automatically generated.

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

Failed: ZOOKEEPER-1971 PreCommit Build #3438

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 479383 lines...]
 [exec] +1 tests included.  The patch appears to include 2 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 2.0.3) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] -1 core tests.  The patch failed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3438//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3438//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3438//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] c02a50ba8e7e083ac6d4ac61165f2359a626e583 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 FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1605: 
exec returned: 1

Total time: 17 minutes 38 seconds
Build step 'Execute shell' marked build as failure
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-1971
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
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-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-1971:
---
Attachment: ZOOKEEPER-1971-03.patch

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-1971:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12828895/ZOOKEEPER-1971-03.patch
  against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.

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

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

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

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

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

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

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

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

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

This message is automatically generated.

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, zookeeperAdmin.pdf, 
> zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

Failed: ZOOKEEPER-1971 PreCommit Build #3436

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 454823 lines...]
 [exec] +1 tests included.  The patch appears to include 2 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 2.0.3) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] -1 core tests.  The patch failed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3436//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3436//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3436//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] 988edccfc497d26ea02ae79cda7e919a5b2acf63 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 FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1605: 
exec returned: 1

Total time: 14 minutes 58 seconds
Build step 'Execute shell' marked build as failure
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-1971
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
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-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-1971:
---
Attachment: (was: ZOOKEEPER-1971-03.patch)

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, zookeeperAdmin.pdf, 
> zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-1971:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12828900/GeneratedDoc-ZOOKEEPER-1971-03.pdf
  against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.

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

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

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

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

This message is automatically generated.

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

Failed: ZOOKEEPER-1971 PreCommit Build #3437

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 110 lines...]
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12828900/GeneratedDoc-ZOOKEEPER-1971-03.pdf
 [exec]   against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] -1 tests included.  The patch doesn't appear to include any new 
or modified tests.
 [exec] Please justify why no new tests are needed 
for this patch.
 [exec] Also please list what manual steps were 
performed to verify this patch.
 [exec] 
 [exec] -1 patch.  The patch command could not apply the patch.
 [exec] 
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3437//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] 2e93ae525db416acb74b532e812657056a34ea5a 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 FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1605: 
exec returned: 1

Total time: 51 seconds
Build step 'Execute shell' marked build as failure
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
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-1971
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
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) 
##
No tests ran.

[jira] [Updated] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-1971:
---
Attachment: GeneratedDoc-ZOOKEEPER-1971-03.pdf

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: GeneratedDoc-ZOOKEEPER-1971-03.pdf, 
> ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, ZOOKEEPER-1971-03.patch, 
> zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

[jira] [Updated] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable

[Arshad Mohammad (JIRA)]

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

Arshad Mohammad updated ZOOKEEPER-1971:
---
Attachment: ZOOKEEPER-1971-03.patch

> Make JMX remote monitoring port configurable
> 
>
> Key: ZOOKEEPER-1971
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1971
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.0
> Environment: All
>Reporter: Biju Nair
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1971-01.patch, ZOOKEEPER-1971-02.patch, 
> ZOOKEEPER-1971-03.patch, zookeeperAdmin.pdf, zookeeperJMX.pdf
>
>
> This is a follow-up item from ZOOKEEPER-1948.



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

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

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 450109 lines...]
[junit] 2016-09-16 20:02:35,016 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-09-16 20:02:35,016 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:16852
[junit] 2016-09-16 20:02:35,015 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x10076455695
[junit] 2016-09-16 20:02:35,022 [myid:] - INFO  [main:ZooKeeperServer@529] 
- shutting down
[junit] 2016-09-16 20:02:35,022 [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-16 20:02:35,022 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-09-16 20:02:35,022 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-09-16 20:02:35,023 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-09-16 20:02:35,023 [myid:] - INFO  [ProcessThread(sid:0 
cport:16852)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-09-16 20:02:35,023 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-09-16 20:02:35,023 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-09-16 20:02:35,024 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port16852,name1=InMemoryDataTree]
[junit] 2016-09-16 20:02:35,024 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port16852]
[junit] 2016-09-16 20:02:35,025 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 16852
[junit] 2016-09-16 20:02:35,025 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-09-16 20:02:35,031 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 1376 at start it was 1376
[junit] 2016-09-16 20:02:35,032 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-09-16 20:02:35,032 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
441.214 sec, Thread: 3, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-09-16 20:02:35,166 [myid:127.0.0.1:16735] - INFO  
[main-SendThread(127.0.0.1:16735):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:16735. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-16 20:02:35,167 [myid:127.0.0.1:16735] - WARN  
[main-SendThread(127.0.0.1:16735):ClientCnxn$SendThread@1235] - Session 
0x30076425495 for server 127.0.0.1/127.0.0.1:16735, 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-16 20:02:35,273 [myid:127.0.0.1:16729] - INFO  
[main-SendThread(127.0.0.1:16729):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:16729. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-16 20:02:35,274 [myid:127.0.0.1:16729] - WARN  
[main-SendThread(127.0.0.1:16729):ClientCnxn$SendThread@1235] - Session 
0x10076425483 for server 127.0.0.1/127.0.0.1:16729, 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-16 20:02:35,351 [myid:127.0.0.1:16608] - INFO  
[main-SendThread(127.0.0.1:16608):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:16608. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-09-16 20:02:35,352 [myid:127.0.0.1:16608] - WARN  
[main-SendThread(127.0.0.1:16608):ClientCnxn$SendThread@1235] - Session 

[SECURITY] CVE-2016-5017: Buffer overflow vulnerability in ZooKeeper C cli shell

[Flavio Junqueira]

Apologies for the duplicate, this report has a correction over the previous 
version sent earlier.

###
CVE-2016-5017: Buffer overflow vulnerability in ZooKeeper C cli shell

Severity: moderate

Vendor:
The Apache Software Foundation

Versions Affected:
ZooKeeper 3.4.0 to 3.4.8
ZooKeeper 3.5.0 to 3.5.2
The unsupported ZooKeeper 1.x through 3.3.x versions may be also affected

Note: The 3.5 branch is still alpha at this time.

Description:
The ZooKeeper C client shells "cli_st" and "cli_mt" have a buffer
overflow vulnerability associated with parsing of the input command
when using the "cmd:" batch mode syntax. If the command string
exceeds 1024 characters a buffer overflow will occur. There is no
known compromise which takes advantage of this vulnerability, and if
security is enabled the attacker would be limited by client level
security constraints. The C cli shell is intended as a sample/example
of how to use the C client interface, not as a production tool - the
documentation has also been clarified on this point.

Mitigation:
It is important to use the fully featured/supported Java cli shell rather
than the C cli shell independent of version.

- ZooKeeper 3.4.x users should upgrade to 3.4.9 or apply this patch:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=27ecf981a15554dc8e64a28630af7a5c9e2bdf4f

- ZooKeeper 3.5.x users should upgrade to 3.5.3 when released or apply
this patch:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=f09154d6648eeb4ec5e1ac8a2bacbd2f8c87c14a

The patch solves the problem reported here, but it does not make the
client ready for production use. The community has no plan to make
this client production ready at this time, and strongly recommends that
users move to the Java cli and use the C cli for illustration purposes only.

Credit:
This issue was discovered by Lyon Yang (@l0Op3r)

References:
https://zookeeper.apache.org/security.html
###

[jira] [Deleted] (ZOOKEEPER-2588) issus of the project

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira deleted ZOOKEEPER-2588:



> issus of the project
> 
>
> Key: ZOOKEEPER-2588
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2588
> Project: ZooKeeper
>  Issue Type: Sub-task
>Reporter: Gandhi
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> sgdfhhj gdfhtgh



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

[jira] [Updated] (ZOOKEEPER-2588) issus of the project

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira updated ZOOKEEPER-2588:


> issus of the project
> 
>
> Key: ZOOKEEPER-2588
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2588
> Project: ZooKeeper
>  Issue Type: Sub-task
>Reporter: Gandhi
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> sgdfhhj gdfhtgh



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

[jira] [Resolved] (ZOOKEEPER-2588) issus of the project

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira resolved ZOOKEEPER-2588.
-

> issus of the project
> 
>
> Key: ZOOKEEPER-2588
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2588
> Project: ZooKeeper
>  Issue Type: Sub-task
>Reporter: Gandhi
> Fix For: 3.4.10
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> sgdfhhj gdfhtgh



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

[jira] [Updated] (ZOOKEEPER-2588) issus of the project

[Flavio Junqueira (JIRA)]

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

Flavio Junqueira updated ZOOKEEPER-2588:


> issus of the project
> 
>
> Key: ZOOKEEPER-2588
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2588
> Project: ZooKeeper
>  Issue Type: Sub-task
>Reporter: Gandhi
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> sgdfhhj gdfhtgh



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

[SECURITY] CVE-2016-5017: Buffer overflow vulnerability in ZooKeeper C cli shell

[Flavio Junqueira]

CVE-2016-5017: Buffer overflow vulnerability in ZooKeeper C cli shell

Severity: moderate

Vendor:
The Apache Software Foundation

Versions Affected:
ZooKeeper 3.4.0 to 3.4.8
ZooKeeper 3.5.0 to 3.5.2
The unsupported ZooKeeper 1.x through 3.3.x versions may be also affected

Note: The 3.5 branch is still alpha at this time.

Description:
The ZooKeeper C client shells "cli_st" and "cli_mt" have a buffer
overflow vulnerability associated with parsing of the input command
when using the "cmd:" batch mode syntax. If the command string
exceeds 1024 characters a buffer overflow will occur. There is no
known compromise which takes advantage of this vulnerability, and if
security is enabled the attacker would be limited by client level
security constraints. The C cli shell is intended as a sample/example
of how to use the C client interface, not as a production tool - the
documentation has also been clarified on this point.

Mitigation:
It is important to use the fully featured/supported Java cli shell rather
than the C cli shell independent of version.

- ZooKeeper 3.4.x users should upgrade to 3.4.9 or apply this patch:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=27ecf981a15554dc8e64a28630af7a5c9e2bdf4f
 


- ZooKeeper 3.5.x users should upgrade to 3.5.3 when released or apply
this patch:
https://git-wip-us.apache.org/repos/asf?p=zookeeper.git;a=commitdiff;h=f09154d6648eeb4ec5e1ac8a2bacbd2f8c87c14a
 


The patch solves the problem reported here, but it does not make the
client ready for production use. The community has no plan to make
this client production ready at this time, and strongly recommends that
users move to the Java cli and use the C cli for illustration purposes only.


Credit:
This issue was discovered by Lyon Yang, an Apple security researcher.

References:
https://zookeeper.apache.org/security.html 

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 6:07 PM:


I am attaching a crude and possible buggy stab at a solution.

My idea with this patch is just to *bootstrap* the discussion about possible 
fixes, so *don't rely on it for being complete (what about multiop?), correct 
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly 
provided, for what's worth. :)

PS: TBH, I *don't* like the idea of 'throttling' the pipeline until setACL 
completes, so I am more than open to hear what you have to say.


was (Author: eribeiro):
I am attaching a crude and possible buggy stab at a solution.

My idea with this patch is just to *bootstrap* the discussion about possible 
fixes, so *don't rely on it for being complete (what about multiop?), correct 
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly 
provided, for what's worth. :)

> 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] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2439:
--
Attachment: ZOOKEEPER-2439-WIP.patch

I am attaching a crude and possible buggy stab at a solution.

My idea with this patch is just to *bootstrap* the discussion about possible 
fixes, so *don't rely on it for being complete (what about multiop?), correct 
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly 
provided, for what's worth. :)

> 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-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-2579:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12828868/ZOOKEEPER-2579_3.4.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 patch.  The patch command could not apply the patch.

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

This message is automatically generated.

> ZooKeeper server should verify that dataDir and snapDir are writeable before 
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch, 
> ZOOKEEPER-2579.patch, ZOOKEEPER-2579_3.4.patch, ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not 
> writeable, the server does not fail until it actually tries to write there. 
> It should fail when it starts.



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

Failed: ZOOKEEPER-2579 PreCommit Build #3435

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 110 lines...]
 [exec] PATCH APPLICATION FAILED
 [exec] 
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12828868/ZOOKEEPER-2579_3.4.patch
 [exec]   against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.
 [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 patch.  The patch command could not apply the patch.
 [exec] 
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3435//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] fe5a4fa3ed28f37bd96af15b07f225c4804dee2f 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 FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1605: 
exec returned: 1

Total time: 50 seconds
Build step 'Execute shell' marked build as failure
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
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2579
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
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) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting

[Abraham Fine (JIRA)]

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

Abraham Fine commented on ZOOKEEPER-2579:
-

[~eribeiro] updated :)

> ZooKeeper server should verify that dataDir and snapDir are writeable before 
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch, 
> ZOOKEEPER-2579.patch, ZOOKEEPER-2579_3.4.patch, ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not 
> writeable, the server does not fail until it actually tries to write there. 
> It should fail when it starts.



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

[jira] [Updated] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2579:

Attachment: ZOOKEEPER-2579_3.4.patch

> ZooKeeper server should verify that dataDir and snapDir are writeable before 
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch, 
> ZOOKEEPER-2579.patch, ZOOKEEPER-2579_3.4.patch, ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not 
> writeable, the server does not fail until it actually tries to write there. 
> It should fail when it starts.



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

[jira] [Updated] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting

[Abraham Fine (JIRA)]

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

Abraham Fine updated ZOOKEEPER-2579:

Attachment: ZOOKEEPER-2579.patch

> ZooKeeper server should verify that dataDir and snapDir are writeable before 
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch, 
> ZOOKEEPER-2579.patch, ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not 
> writeable, the server does not fail until it actually tries to write there. 
> It should fail when it starts.



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

[jira] [Created] (ZOOKEEPER-2588) issus of the project

[Gandhi (JIRA)]

Gandhi created ZOOKEEPER-2588:
-

 Summary: issus of the project
 Key: ZOOKEEPER-2588
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2588
 Project: ZooKeeper
  Issue Type: Sub-task
Affects Versions: 3.4.8
Reporter: Gandhi
 Fix For: 3.4.10


sgdfhhj gdfhtgh



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

ZooKeeper_branch35_solaris - Build # 252 - Still Failing

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 455090 lines...]
[junit] 2016-09-16 17:26:27,416 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-09-16 17:26:27,416 [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-09-16 17:26:27,416 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-09-16 17:26:27,417 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-09-16 17:26:27,417 [myid:] - INFO  [main:ZooKeeperServer@889] 
- minSessionTimeout set to 6000
[junit] 2016-09-16 17:26:27,417 [myid:] - INFO  [main:ZooKeeperServer@898] 
- maxSessionTimeout set to 6
[junit] 2016-09-16 17:26:27,418 [myid:] - INFO  [main:ZooKeeperServer@159] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test2389261188333985316.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test2389261188333985316.junit.dir/version-2
[junit] 2016-09-16 17:26:27,418 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test2389261188333985316.junit.dir/version-2/snapshot.b
[junit] 2016-09-16 17:26:27,420 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test2389261188333985316.junit.dir/version-2/snapshot.b
[junit] 2016-09-16 17:26:27,421 [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-16 17:26:27,422 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-09-16 17:26:27,422 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:61899
[junit] 2016-09-16 17:26:27,423 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:61899
[junit] 2016-09-16 17:26:27,423 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-09-16 17:26:27,423 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:61899 (no session established for client)
[junit] 2016-09-16 17:26:27,423 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-09-16 17:26:27,424 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17780
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-09-16 17:26:27,425 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-09-16 17:26:27,426 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-09-16 17:26:27,502 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x123b10449db closed
[junit] 2016-09-16 17:26:27,502 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x123b10449db
[junit] 2016-09-16 17:26:27,502 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-09-16 17:26:27,503 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-09-16 17:26:27,503 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-09-16 17:26:27,503 [myid:] - INFO  

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 3:37 PM:


Hi [~kazuakibanzai],

I took some time to dig this problem and I *guess* I've found the root cause. 
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear 
from some ZK committers as to deny or confirm my idea (and took the liberty of 
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]

First and foremost, *huge thanks* for the patch to simulate the bug, it helped 
a lot. Well, let's start: in a nutshell, the server side ZK is an ordered 
processing pipeline of RequestProcessors, where each processor is handled by a 
different Thread. The one that is interesting to this particular case looks 
like this (I am a newbie, so I may get something wrong):

{code}
request -->  PrepRequestProcessor > SyncRequestsProcessor  
--> FinalRequestProcessor --> [request applied and committed]
{code}

*KEEP THIS IN MIND:* A request is committed to ZK database as well as having 
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}} 
without any exception.

a. One request can be currently being processed at {{PrepRequestProcessor}} 
while another one is either {{SyncRequestsProcessor}} or 
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests, 
one in each step of the pipeline under high load, for example.

b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is 
well formed as well as authorization and ACL permissions (it makes sense as 
SyncRequestProcessor, among other things, saves the log file and we wouldn't 
want to record an invalid request on command log, right?). *KEEP THIS IN MIND 
TOO:* ACL checks are done at the first stage of the pipeline.


*_So, the problem you described can be summarised as such:_*

1. a setACL request that removes access to '/' (let's call it REQ1) is sent 
asynchronously, followed by a create a znode under '/a' request (let's call it 
REQ2). Both are enqueued in order and arrive in this order on the server side.

2. REQ1 passes {{PrepRequestProcessor}}.

3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at 
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that 
REQ2 has the ACL rights to create the node, because REQ1 was not committed to 
ZK DB yet (it's in the middle of the pipeline).

4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the 
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent 
REQ2 from being applied! Remember the permission was check on 
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still 
ongoing.

*_Now let's see why some scenarios that explain your unit test:_*

Case 1: The sync ACL call is, well, synchronous so, it wait for a response 
before sending the next command (createNode). Therefore, REQ1 completes the 
pipeline before REQ2 even reaches the it and the createNode is rejected as 
expected.

Case 2. If you put a sleep between async setACL and createNode then you gave 
some time to REQ1 finish the pipeline because REQ2 will be inserted into the 
client outgoing queue after the sleep time. Again, this succeeds by rejecting 
the createNode command.

Case 3. If you insert async or sync setACL commands before the createNode you 
are "stuffing" additional commands between setACL and createNode. Again giving 
a chance of setACL finishes before the createdNode reaches the first stage of 
the pipeline. Then again, it works as expected (the createNode is rejected).

Finally, another conjecture I have is that this setACL/createNode behavior 
could happen if with synchronous setACL. If we had two clients, the first one 
could issue a sync setACL and the second one a createNode, and with the right 
timing they would be enqueued as explained above.

Does it make sense?






was (Author: eribeiro):
Hi [~kazuakibanzai],

I took some time to dig this problem and I *guess* I've found the root cause. 
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear 
from some ZK committers as to deny or confirm my idea (and took the liberty of 
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]

First and foremost, *huge thanks* for the patch to simulate the bug, it helped 
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing 
pipeline of RequestProcessors. The one that is interesting to this particular 
case looks like this (I am a newbie, so I may get something wrong):

{code}
request -->  PrepRequestProcessor > SyncRequestsProcessor  
--> FinalRequestProcessor --> [request applied and committed]
{code}

*KEEP THIS IN MIND:* A request is committed to 

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 3:35 PM:


Hi [~kazuakibanzai],

I took some time to dig this problem and I *guess* I've found the root cause. 
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear 
from some ZK committers as to deny or confirm my idea (and took the liberty of 
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]

First and foremost, *huge thanks* for the patch to simulate the bug, it helped 
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing 
pipeline of RequestProcessors. The one that is interesting to this particular 
case looks like this (I am a newbie, so I may get something wrong):

{code}
request -->  PrepRequestProcessor > SyncRequestsProcessor  
--> FinalRequestProcessor --> [request applied and committed]
{code}

*KEEP THIS IN MIND:* A request is committed to ZK database as well as having 
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}} 
without any exception.

a. One request can be currently being processed at {{PrepRequestProcessor}} 
while another one is either {{SyncRequestsProcessor}} or 
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests, 
one in each step of the pipeline under high load, for example.

b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is 
well formed as well as authorization and ACL permissions (it makes sense as 
SyncRequestProcessor, among other things, saves the log file and we wouldn't 
want to record an invalid request on command log, right?). *KEEP THIS IN MIND 
TOO:* ACL checks are done at the first stage of the pipeline.


*_So, the problem you described can be summarised as such:_*

1. a setACL request that removes access to '/' (let's call it REQ1) is sent 
asynchronously, followed by a create a znode under '/a' request (let's call it 
REQ2). Both are enqueued in order and arrive in this order on the server side.

2. REQ1 passes {{PrepRequestProcessor}}.

3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at 
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that 
REQ2 has the ACL rights to create the node, because REQ1 was not committed to 
ZK DB yet (it's in the middle of the pipeline).

4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the 
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent 
REQ2 from being applied! Remember the permission was check on 
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still 
ongoing.

*_Now let's see why some scenarios that explain your unit test:_*

Case 1: The sync ACL call is, well, synchronous so, it wait for a response 
before sending the next command (createNode). Therefore, REQ1 completes the 
pipeline before REQ2 even reaches the it and the createNode is rejected as 
expected.

Case 2. If you put a sleep between async setACL and createNode then you gave 
some time to REQ1 finish the pipeline because REQ2 will be inserted into the 
client outgoing queue after the sleep time. Again, this succeeds by rejecting 
the createNode command.

Case 3. If you insert async or sync setACL commands before the createNode you 
are "stuffing" additional commands between setACL and createNode. Again giving 
a chance of setACL finishes before the createdNode reaches the first stage of 
the pipeline. Then again, it works as expected (the createNode is rejected).

Finally, another conjecture I have is that this setACL/createNode behavior 
could happen if with synchronous setACL. If we had two clients, the first one 
could issue a sync setACL and the second one a createNode, and with the right 
timing they would be enqueued as explained above.

Does it make sense?






was (Author: eribeiro):
Hi [~kazuakibanzai],

I took some time to dig this problem and I *guess* I've found the root cause. 
*Disclaimer: I can be totally wrong on my assumptions, so would love to see 
some ZK committers about this as to deny or confirm my idea (and took the 
liberty of marking them on this message, sorry guys).* /cc [~fpj], [~breed], 
[~phunt]

First and foremost, *huge thanks* for the patch to simulate the bug, it helped 
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing 
pipeline of RequestProcessors. The one that is interesting to this particular 
case looks like this (I am a newbie, so I may get something wrong):

{code}
request -->  PrepRequestProcessor > SyncRequestsProcessor  
--> FinalRequestProcessor --> [request applied and committed]
{code}

*KEEP THIS IN MIND:* A request is committed to ZK database as well as having 
the logs and snapshots 

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2439:
--
Assignee: (was: Edward Ribeiro)

> 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.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-2439) The order of asynchronous setACL is not correct.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2439:
---

Hi [~kazuakibanzai],

I took some time to dig this problem and I *guess* I've found the root cause. 
*Disclaimer: I can be totally wrong on my assumptions, so would love to see 
some ZK committers about this as to deny or confirm my idea (and took the 
liberty of marking them on this message, sorry guys).* /cc [~fpj], [~breed], 
[~phunt]

First and foremost, *huge thanks* for the patch to simulate the bug, it helped 
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing 
pipeline of RequestProcessors. The one that is interesting to this particular 
case looks like this (I am a newbie, so I may get something wrong):

{code}
request -->  PrepRequestProcessor > SyncRequestsProcessor  
--> FinalRequestProcessor --> [request applied and committed]
{code}

*KEEP THIS IN MIND:* A request is committed to ZK database as well as having 
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}} 
without any exception.

a. One request can be currently being processed at {{PrepRequestProcessor}} 
while another one is either {{SyncRequestsProcessor}} or 
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests, 
one in each step of the pipeline under high load, for example.

b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is 
well formed as well as authorization and ACL permissions (it makes sense as 
SyncRequestProcessor, among other things, saves the log file and we wouldn't 
want to record an invalid request on command log, right?). *KEEP THIS IN MIND 
TOO:* ACL checks are done at the first stage of the pipeline.


*_So, the problem you described can be summarised as such:_*

1. a setACL request that removes access to '/' (let's call it REQ1) is sent 
asynchronously, followed by a create a znode under '/a' request (let's call it 
REQ2). Both are enqueued in order and arrive in this order on the server side.

2. REQ1 passes {{PrepRequestProcessor}}.

3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at 
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that 
REQ2 has the ACL rights to create the node, because REQ1 was not committed to 
ZK DB yet (it's in the middle of the pipeline).

4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the 
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent 
REQ2 from being applied! Remember the permission was check on 
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still 
ongoing.

*_Now let's see why some scenarios that explain your unit test:_*

Case 1: The sync ACL call is, well, synchronous so, it wait for a response 
before sending the next command (createNode). Therefore, REQ1 completes the 
pipeline before REQ2 even reaches the it and the createNode is rejected as 
expected.

Case 2. If you put a sleep between async setACL and createNode then you gave 
some time to REQ1 finish the pipeline because REQ2 will be inserted into the 
client outgoing queue after the sleep time. Again, this succeeds by rejecting 
the createNode command.

Case 3. If you insert async or sync setACL commands before the createNode you 
are "stuffing" additional commands between setACL and createNode. Again giving 
a chance of setACL finishes before the createdNode reaches the first stage of 
the pipeline. Then again, it works as expected (the createNode is rejected).

Finally, another conjecture I have is that this setACL/createNode behavior 
could happen if with synchronous setACL. If we had two clients, the first one 
could issue a sync setACL and the second one a createNode, and with the right 
timing they would be enqueued as explained above.

Does it make sense?





> 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
>Assignee: Edward Ribeiro
>  Labels: acl
> Attachments: 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 

[jira] [Comment Edited] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2579 at 9/16/16 1:27 PM:


{quote}
I guess it would be reasonable to say that the tests that I wrote are more like 
integration tests while the tests that you attached are true unit tests. I 
guess it could be argued that most of the tests in ZooKeeperServerMainTest are 
really integration tests.
{quote}

Yup, I agree.

{quote}
It would be possible to include both types of test instead of needing to 
choose. What do you think?
{quote}

Sounds good to me. In fact, it's up to you leave the 
{{FileTxnSnapLogTest.java}} or not. :) Let's see what the committers say, but I 
am okay with either approach, at first. 

*By the way, thanks for pointing out {{testWithoutAutoCreateDataLogDir}} 
because it reminded me that it would be nice to include the timeout (i.e., 
{{@Test(timeout = 3)}}) in those kind of tests. Please, update your patch 
accordingly. ;)* 

Best regards,


was (Author: eribeiro):
{quote}
I guess it would be reasonable to say that the tests that I wrote are more like 
integration tests while the tests that you attached are true unit tests. I 
guess it could be argued that most of the tests in ZooKeeperServerMainTest are 
really integration tests.
{quote}

Yup, I agree.

{quote}
It would be possible to include both types of test instead of needing to 
choose. What do you think?
{quote}

Sounds good to me. In fact, it's up to you leave the 
{{FileTxnSnapLogTest.java}} or not. :) Let's see what the committers say, but I 
am okay with either approach, at first. 

By the way, thanks for pointing out 
{{ZooKeeperServerMainTest.testWithoutAutoCreateDataLogDir}} because it reminded 
me that it would be nice to include the timeout (i.e., {{@Test(timeout = 
3)}}) in those kind of tests.

Best regards,

> ZooKeeper server should verify that dataDir and snapDir are writeable before 
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch, 
> ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not 
> writeable, the server does not fail until it actually tries to write there. 
> It should fail when it starts.



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

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

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 456241 lines...]
[junit] 2016-09-16 13:10:29,705 [myid:127.0.0.1:21994] - WARN  
[main-SendThread(127.0.0.1:21994):ClientCnxn$SendThread@1235] - Session 
0x100c59643f1 for server 127.0.0.1/127.0.0.1:21994, 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-16 13:10:29,707 [myid:] - INFO  [ProcessThread(sid:0 
cport:22238)::PrepRequestProcessor@647] - Processed session termination for 
sessionid: 0x100c59d0919
[junit] 2016-09-16 13:10:29,707 [myid:] - WARN  [New I/O worker 
#6635:NettyServerCnxnFactory$CnxnChannelHandler@142] - Exception caught [id: 
0x43bcb498, /127.0.0.1:52470 => /127.0.0.1:22238] EXCEPTION: 
java.nio.channels.ClosedChannelException
[junit] java.nio.channels.ClosedChannelException
[junit] at 
sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:270)
[junit] at 
sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:461)
[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:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-09-16 13:10:29,707 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port22238,name1=Connections,name2=127.0.0.1,name3=0x100c59d0919]
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x100c59d0919 closed
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 172749
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1643
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-09-16 13:10:29,809 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-09-16 13:10:29,809 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:22238
[junit] 2016-09-16 13:10:29,808 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x100c59d0919
[junit] 2016-09-16 13:10:29,814 [myid:] - INFO  [main:ZooKeeperServer@529] 
- shutting down
[junit] 2016-09-16 13:10:29,814 [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-16 13:10:29,814 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-09-16 13:10:29,814 [myid:] - INFO  
[main:PrepRequestProcessor@965] - Shutting down
[junit] 2016-09-16 13:10:29,814 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-09-16 13:10:29,814 [myid:] - INFO  [ProcessThread(sid:0 
cport:22238)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-09-16 13:10:29,815 [myid:] - INFO  

[jira] [Updated] (ZOOKEEPER-2531) Configuration as "zookeeper.secure=true/false" can be introduced and reading and verifying all ssl related configuration (like secureport, keystore, truststore, corre

[Rakesh Kumar Singh (JIRA)]

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

Rakesh Kumar Singh updated ZOOKEEPER-2531:
--
Priority: Major  (was: Minor)

> Configuration as "zookeeper.secure=true/false" can be introduced and reading 
> and verifying all ssl related configuration (like secureport, keystore, 
> truststore, corresponding password) should be done only when 
> "zookeeper.secure" flag is true
> -
>
> Key: ZOOKEEPER-2531
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2531
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>
> Configuration as "zookeeper.secure=true/false" can be introduced and reading 
> and verifying all ssl related configuration (like secureport, keystore, 
> truststore, corresponding password) should be done only when 
> "zookeeper.secure" flag is true



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

Failed: ZOOKEEPER-2251 PreCommit Build #3434

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 122 lines...]
 [exec] PATCH APPLICATION FAILED
 [exec] 
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12791733/ZOOKEEPER-2251-04.patch
 [exec]   against trunk revision b2a484cfe743116d2531fe5d1e1d78b3960c511e.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 2 new or 
modified tests.
 [exec] 
 [exec] -1 patch.  The patch command could not apply the patch.
 [exec] 
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3434//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] f67dcc1ce6afe4048245731347169ddd0f695365 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 FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1605: 
exec returned: 1

Total time: 47 seconds
Build step 'Execute shell' marked build as failure
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
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2251
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
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) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-2251) Add Client side packet response timeout to avoid infinite wait.

[Hadoop QA (JIRA)]

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

Hadoop QA commented on ZOOKEEPER-2251:
--

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

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

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

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

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

This message is automatically generated.

> Add Client side packet response timeout to avoid infinite wait.
> ---
>
> Key: ZOOKEEPER-2251
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2251
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: nijel
>Assignee: Arshad Mohammad
> Attachments: ZOOKEEPER-2251-01.patch, ZOOKEEPER-2251-02.patch, 
> ZOOKEEPER-2251-03.patch, ZOOKEEPER-2251-04.patch
>
>
> I came across one issue related to Client side packet response timeout In my 
> cluster many packet drops happened for some time.
> One observation is the zookeeper client got hanged. As per the thread dump it 
> is waiting for the response/ACK for the operation performed (synchronous API 
> used here).
> I am using 
> zookeeper.serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
> Since only few packets missed there is no DISCONNECTED event occurred.
> Need add a "response time out" for the operations or packets.
> *Comments from [~rakeshr]*
> My observation about the problem:-
> * Can use tools like 'Wireshark' to simulate the artificial packet loss.
> * Assume there is only one packet in the 'outgoingQueue' and unfortunately 
> the server response packet lost. Now, client will enter into infinite 
> waiting. 
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1515
> * Probably we can discuss more about this problem and possible solutions(add 
> packet ACK timeout or another better approach) in the jira.



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