[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833893#comment-15833893
]
Arshad Mohammad commented on ZOOKEEPER-2671:
[~eribeiro], yes it is failing in CI as well [CI Failure
Link|https://builds.apache.org/job/ZooKeeper_branch34_jdk7/1375/]
> Compilation error in branch-3.4
> ---
>
> Key: ZOOKEEPER-2671
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-2671-01.patch
>
>
> branch-3.4 code compilation is failing. Following are the compilation erros:
> {code}
> compile-test:
> [mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] Compiling 146 source files to
> D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac]
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
> error: cannot find symbol
> [javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
> [javac] ^
> [javac] symbol: method createZKClient(String)
> [javac] location: class ClientBase
> [javac]
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
> error: cannot find symbol
> [javac] zk = ClientBase.createZKClient(HOSTPORT);
> [javac]^
> [javac] symbol: method createZKClient(String)
> [javac] location: class ClientBase
> [javac] Note: Some input files use or override a deprecated API.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2671) Compilation error in branch-3.4
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2671:
---
Attachment: ZOOKEEPER-2671-01.patch
> Compilation error in branch-3.4
> ---
>
> Key: ZOOKEEPER-2671
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Attachments: ZOOKEEPER-2671-01.patch
>
>
> branch-3.4 code compilation is failing. Following are the compilation erros:
> {code}
> compile-test:
> [mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] Compiling 146 source files to
> D:\gitHome\zookeeperTrunk\build\test\classes
> [javac] warning: [options] bootstrap class path not set in conjunction
> with -source 1.6
> [javac]
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
> error: cannot find symbol
> [javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
> [javac] ^
> [javac] symbol: method createZKClient(String)
> [javac] location: class ClientBase
> [javac]
> D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
> error: cannot find symbol
> [javac] zk = ClientBase.createZKClient(HOSTPORT);
> [javac]^
> [javac] symbol: method createZKClient(String)
> [javac] location: class ClientBase
> [javac] Note: Some input files use or override a deprecated API.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2671) Compilation error in branch-3.4
Arshad Mohammad created ZOOKEEPER-2671:
--
Summary: Compilation error in branch-3.4
Key: ZOOKEEPER-2671
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2671
Project: ZooKeeper
Issue Type: Bug
Components: server
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
branch-3.4 code compilation is failing. Following are the compilation erros:
{code}
compile-test:
[mkdir] Created dir: D:\gitHome\zookeeperTrunk\build\test\classes
[javac] Compiling 146 source files to
D:\gitHome\zookeeperTrunk\build\test\classes
[javac] warning: [options] bootstrap class path not set in conjunction with
-source 1.6
[javac]
D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:464:
error: cannot find symbol
[javac] ZooKeeper zk = ClientBase.createZKClient(HOSTPORT);
[javac] ^
[javac] symbol: method createZKClient(String)
[javac] location: class ClientBase
[javac]
D:\gitHome\zookeeperTrunk\src\java\test\org\apache\zookeeper\server\PurgeTxnTest.java:503:
error: cannot find symbol
[javac] zk = ClientBase.createZKClient(HOSTPORT);
[javac]^
[javac] symbol: method createZKClient(String)
[javac] location: class ClientBase
[javac] Note: Some input files use or override a deprecated API.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ZOOKEEPER-2660) acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad resolved ZOOKEEPER-2660.
Resolution: Duplicate
> acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
>
>
> Key: ZOOKEEPER-2660
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2660
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.4.6, 3.4.9
> Environment: ZK: 3.4.9
>Reporter: Yongcheng Liu
>
> 1. currentEpoch is bigger than acceptedEpoch, ZK will throw IOException when
> start loadDataBase.
> 2. function bug. In function setAcceptedEpoch and setCurrentEpoch, it is
> modify memory variable first, then write epoch to file. If write file failed,
> the memory has been modified.
> solution as follow:
> for example,
> public void setAcceptedEpoch(long e) throws IOException {
> acceptedEpoch = e;
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> }
> need to modify as follow:
> public void setAcceptedEpoch(long e) throws IOException {
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> acceptedEpoch = e;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2660) acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15832183#comment-15832183
]
Arshad Mohammad edited comment on ZOOKEEPER-2660 at 1/20/17 6:02 PM:
-
Thanks [~Yongcheng] for reporting this issue, though it is duplicate of
ZOOKEEPER-2307. I am closing it as duplicate. Please feel free to reopen If you
disagree.
was (Author: arshad.mohammad):
Thanks [~Yongcheng] for reporting this issue, though it is duplicate of
ZOOKEEPER-2660. I am closing it as duplicate. Please feel free to reopen If you
disagree.
> acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
>
>
> Key: ZOOKEEPER-2660
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2660
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.4.6, 3.4.9
> Environment: ZK: 3.4.9
>Reporter: Yongcheng Liu
>
> 1. currentEpoch is bigger than acceptedEpoch, ZK will throw IOException when
> start loadDataBase.
> 2. function bug. In function setAcceptedEpoch and setCurrentEpoch, it is
> modify memory variable first, then write epoch to file. If write file failed,
> the memory has been modified.
> solution as follow:
> for example,
> public void setAcceptedEpoch(long e) throws IOException {
> acceptedEpoch = e;
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> }
> need to modify as follow:
> public void setAcceptedEpoch(long e) throws IOException {
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> acceptedEpoch = e;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2660) acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15832183#comment-15832183
]
Arshad Mohammad commented on ZOOKEEPER-2660:
Thanks [~Yongcheng] for reporting this issue, though it is duplicate of
ZOOKEEPER-2660. I am closing it as duplicate. Please feel free to reopen If you
disagree.
> acceptedEpoch and currentEpoch data inconsistency, ZK process can not start!
>
>
> Key: ZOOKEEPER-2660
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2660
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.4.6, 3.4.9
> Environment: ZK: 3.4.9
>Reporter: Yongcheng Liu
>
> 1. currentEpoch is bigger than acceptedEpoch, ZK will throw IOException when
> start loadDataBase.
> 2. function bug. In function setAcceptedEpoch and setCurrentEpoch, it is
> modify memory variable first, then write epoch to file. If write file failed,
> the memory has been modified.
> solution as follow:
> for example,
> public void setAcceptedEpoch(long e) throws IOException {
> acceptedEpoch = e;
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> }
> need to modify as follow:
> public void setAcceptedEpoch(long e) throws IOException {
> writeLongToFile(ACCEPTED_EPOCH_FILENAME, e);
> acceptedEpoch = e;
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2577) Flaky Test: org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15824117#comment-15824117
]
Arshad Mohammad commented on ZOOKEEPER-2577:
Test case expectation is wrong. Test case is expecting the old leader to be the
follower only, which is not correct.
Old leader can become the leader again. I will soon raise a merge request.
> Flaky Test:
> org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync
>
>
> Key: ZOOKEEPER-2577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2577
> Project: ZooKeeper
> Issue Type: Test
> Components: tests
>Affects Versions: 3.5.2
>Reporter: Michael Han
>Assignee: Arshad Mohammad
> Labels: flaky, flaky-test
> Fix For: 3.6.0
>
>
> This failure is new and consistent on jdk7/8 with trunk branch - happened
> after build 3070 recently. Not sure if this is caused by svn - git migration
> or not.
> {noformat}
> Error Message
> zoo.cfg.dynamic.next is not deleted.
> Stacktrace
> junit.framework.AssertionFailedError: zoo.cfg.dynamic.next is not deleted.
> at
> org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync(ReconfigDuringLeaderSyncTest.java:155)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)
> Standard Output
> 2016-09-13 05:09:25,247 [myid:] - INFO [main:JUnit4ZKTestRunner@47] - No
> test.method specified. using default methods.
> 2016-09-13 05:09:25,349 [myid:] - INFO [main:JUnit4ZKTestRunner@47] - No
> test.method specified. using default methods.
> 2016-09-13 05:09:25,370 [myid:] - INFO [main:ZKTestCase$1@55] - STARTING
> testDuringLeaderSync
> 2016-09-13 05:09:25,372 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD
> testDuringLeaderSync
> 2016-09-13 05:09:25,375 [myid:] - INFO [main:PortAssignment@151] - Test
> process 2/8 using ports from 13914 - 16606.
> 2016-09-13 05:09:25,380 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13915 from range 13914 - 16606.
> 2016-09-13 05:09:25,380 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13916 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13917 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13918 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13919 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13920 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13921 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13922 from range 13914 - 16606.
> 2016-09-13 05:09:25,383 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13923 from range 13914 - 16606.
> 2016-09-13 05:09:25,406 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 0 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test8397079557861207505.junit.dir
> clientPort = 13915 adminServerPort = 8080
> 2016-09-13 05:09:25,416 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 1 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test176919429940621.junit.dir
> clientPort = 13918 adminServerPort = 8080
> 2016-09-13 05:09:25,420 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 2 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test5455612786130415623.junit.dir
> clientPort = 13921 adminServerPort = 8080
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-0:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test8397079557861207505.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-2:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test5455612786130415623.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-1:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test176919429940621.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,424 [myid:] - INFO [main:FourLetterWordMain@85] -
> connecting to 127.0.0.1 13915
> 2016-09-13 05:09:25,425 [myid:] - INFO [Thread-0:QuorumPeerConfig@318] -
> clientPortAddress is
[jira] [Assigned] (ZOOKEEPER-2577) Flaky Test: org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad reassigned ZOOKEEPER-2577:
--
Assignee: Arshad Mohammad
> Flaky Test:
> org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync
>
>
> Key: ZOOKEEPER-2577
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2577
> Project: ZooKeeper
> Issue Type: Test
> Components: tests
>Affects Versions: 3.5.2
>Reporter: Michael Han
>Assignee: Arshad Mohammad
> Labels: flaky, flaky-test
> Fix For: 3.6.0
>
>
> This failure is new and consistent on jdk7/8 with trunk branch - happened
> after build 3070 recently. Not sure if this is caused by svn - git migration
> or not.
> {noformat}
> Error Message
> zoo.cfg.dynamic.next is not deleted.
> Stacktrace
> junit.framework.AssertionFailedError: zoo.cfg.dynamic.next is not deleted.
> at
> org.apache.zookeeper.server.quorum.ReconfigDuringLeaderSyncTest.testDuringLeaderSync(ReconfigDuringLeaderSyncTest.java:155)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:79)
> Standard Output
> 2016-09-13 05:09:25,247 [myid:] - INFO [main:JUnit4ZKTestRunner@47] - No
> test.method specified. using default methods.
> 2016-09-13 05:09:25,349 [myid:] - INFO [main:JUnit4ZKTestRunner@47] - No
> test.method specified. using default methods.
> 2016-09-13 05:09:25,370 [myid:] - INFO [main:ZKTestCase$1@55] - STARTING
> testDuringLeaderSync
> 2016-09-13 05:09:25,372 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@77] - RUNNING TEST METHOD
> testDuringLeaderSync
> 2016-09-13 05:09:25,375 [myid:] - INFO [main:PortAssignment@151] - Test
> process 2/8 using ports from 13914 - 16606.
> 2016-09-13 05:09:25,380 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13915 from range 13914 - 16606.
> 2016-09-13 05:09:25,380 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13916 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13917 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13918 from range 13914 - 16606.
> 2016-09-13 05:09:25,381 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13919 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13920 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13921 from range 13914 - 16606.
> 2016-09-13 05:09:25,382 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13922 from range 13914 - 16606.
> 2016-09-13 05:09:25,383 [myid:] - INFO [main:PortAssignment@85] - Assigned
> port 13923 from range 13914 - 16606.
> 2016-09-13 05:09:25,406 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 0 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test8397079557861207505.junit.dir
> clientPort = 13915 adminServerPort = 8080
> 2016-09-13 05:09:25,416 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 1 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test176919429940621.junit.dir
> clientPort = 13918 adminServerPort = 8080
> 2016-09-13 05:09:25,420 [myid:] - INFO
> [main:QuorumPeerTestBase$MainThread@131] - id = 2 tmpDir =
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test5455612786130415623.junit.dir
> clientPort = 13921 adminServerPort = 8080
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-0:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test8397079557861207505.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-2:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test5455612786130415623.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,422 [myid:] - INFO [Thread-1:QuorumPeerConfig@116] -
> Reading configuration from:
> /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/build/test/tmp/test176919429940621.junit.dir/zoo.cfg
> 2016-09-13 05:09:25,424 [myid:] - INFO [main:FourLetterWordMain@85] -
> connecting to 127.0.0.1 13915
> 2016-09-13 05:09:25,425 [myid:] - INFO [Thread-0:QuorumPeerConfig@318] -
> clientPortAddress is 0.0.0.0/0.0.0.0:13915
> 2016-09-13 05:09:25,425 [myid:] - INFO [Thread-0:QuorumPeerConfig@322] -
> secureClientPort is not set
> 2016-09-13 05:09:25,425 [myid:] - INFO [Thread-1:QuorumPeerConfig@318] -
>
[jira] [Commented] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15572954#comment-15572954
]
Arshad Mohammad commented on ZOOKEEPER-2355:
Thanks [~rakeshr],
Addressed all the comments, submitted new patch.
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch, ZOOKEEPER-2355-05.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2355:
---
Attachment: ZOOKEEPER-2355-05.patch
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch, ZOOKEEPER-2355-05.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2570) ZooKeeper clients are timed out when ZooKeeper servers are very busy
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2570:
---
Attachment: ZOOKEEPER-2570-01.patch
Submitting a test patch
> ZooKeeper clients are timed out when ZooKeeper servers are very busy
>
>
> Key: ZOOKEEPER-2570
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2570
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ZOOKEEPER-2570-01.patch
>
>
> ZooKeeper clients are timed out when ZooKeeper servers are very busy. Clients
> throw below exception and fail all the pending operations
> {code}
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
> {code}
> Clients log bellow information
> {noformat}
> 2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - WARN
> [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client
> session timed out, have not heard from server in 13908ms for sessionid
> 0x2d21b28
> 2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - INFO
> [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client
> session timed out, have not heard from server in 13908ms for sessionid
> 0x2d21b28, closing socket connection and attempting reconnect
> {noformat}
> *STEPS TO REPRODECE:*
> # Create multi operation
> {code}
> List ops = new ArrayList();
> for (int i = 0; i < N; i++) {
> Op create = Op.create(rootNode + "/" + i, "".getBytes(),
> ZooDefs.Ids.OPEN_ACL_UNSAFE,
> CreateMode.PERSISTENT);
> ops.add(create);
> }
> {code}
> Chose N in such a way that the total multi operation request size is less
> than but near 1 MB. For bigger request size increase jute.maxbuffer in
> servers
> # Submit the multi operation request
> {code} zooKeeper.multi(ops);{code}
> # After repeating above steps few times issue is reproduced
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2397) Undocumented SASL properties
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541733#comment-15541733
]
Arshad Mohammad commented on ZOOKEEPER-2397:
bq. kinit is a command, not a configuration parameter, right?
In general kinit is a command but in ZooKeeper it is also a configuration which
specifies the path to kinit binary. Default value of this configuration is
/usr/bin/kinit
Reference: org.apache.zookeeper.common.ZKConfig.KINIT_COMMAND
{code}
/**
* Path to a kinit binary: {@value}. Defaults to
* "/usr/bin/kinit"
*/
public static final String KINIT_COMMAND = "zookeeper.kinit";
{code}
> Undocumented SASL properties
>
>
> Key: ZOOKEEPER-2397
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2397
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: documentation
>Affects Versions: 3.4.8, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2397.patch
>
>
> There are a number of properties spread across the code that do not appear in
> the docs. For example, zookeeper.allowSaslFailedClients isn't documented
> afaict.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2397) Undocumented SASL properties
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15541708#comment-15541708 ] Arshad Mohammad commented on ZOOKEEPER-2397: Yes, the remaining work is to figure out and document server side properties. > Undocumented SASL properties > > > Key: ZOOKEEPER-2397 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2397 > Project: ZooKeeper > Issue Type: Sub-task > Components: documentation >Affects Versions: 3.4.8, 3.5.1 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira > Fix For: 3.4.10, 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2397.patch > > > There are a number of properties spread across the code that do not appear in > the docs. For example, zookeeper.allowSaslFailedClients isn't documented > afaict. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2496) When inside a transaction, some exceptions do not have path information set.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518596#comment-15518596 ] Arshad Mohammad edited comment on ZOOKEEPER-2496 at 9/24/16 7:46 AM: - Async multi API does process the result and also it does not throw exception. Result is processed in the callback handler I think the logic to find path of failed operation should be written in the callback handler. Any thought? I am just re-basing the ZOOKEEPER-2276 patch was (Author: arshad.mohammad): Async multi API does process the result and also it does not throw execption. Result is processed in the callback handler I think the logic to find path of transaction should be written in the callback handler. Any thought? I am just re-basing the ZOOKEEPER-2276 patch > When inside a transaction, some exceptions do not have path information set. > > > Key: ZOOKEEPER-2496 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2496 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 >Reporter: Kazuaki Banzai > Attachments: transactionException.patch > > > If a client tries to execute some illegal operations inside a transaction, > ZooKeeper throws an exception. > Some exceptions such as NodeExistsException should have a path to indicate > where the exception occurred. > ZooKeeper clients can get the path by calling method getPath. > However, this method returns null if the exception occurs inside a > transaction. > For example, when a client calls create /a and create /a in a transaction, > ZooKeeper throws NodeExistsException but getPath returns null. > In normal operation (outside transactions), the path information is set > correctly. > The patch only shows this bug occurs with NoNode exception and NodeExists > exception, > but this bug seems to occur with any exception which needs a path information: > When an error occurred in a transaction, ZooKeeper creates an ErrorResult > instance to represent error result. > However, the ErrorResult class doesn't have a field for a path where an error > occurred(See src/java/main/org/apache/zookeeper/OpResult.java for more > details). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2276) Multi operation failure does not include path in KeeperException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-2276: --- Attachment: ZOOKEEPER-2276-02.patch > Multi operation failure does not include path in KeeperException > - > > Key: ZOOKEEPER-2276 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2276 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.0 > Environment: Suse 11 SP3 >Reporter: neha >Assignee: Arshad Mohammad >Priority: Minor > Fix For: 3.5.3 > > Attachments: ZOOKEEPER-2276-01.patch, ZOOKEEPER-2276-02.patch > > > With normal create operation, the path of the failed node is displayed in > KeeperException but this is not the case when create operation is through > multi api -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2276) Multi operation failure does not include path in KeeperException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518624#comment-15518624 ] Arshad Mohammad commented on ZOOKEEPER-2276: Async multi API does process the result and also it does not throw exception. Result is processed in the callback handler I think the logic to find path of failed transaction should be written in the callback handler. So no changed with respect to async multip API. submitting the res-based patch > Multi operation failure does not include path in KeeperException > - > > Key: ZOOKEEPER-2276 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2276 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.0 > Environment: Suse 11 SP3 >Reporter: neha >Assignee: Arshad Mohammad >Priority: Minor > Fix For: 3.5.3 > > Attachments: ZOOKEEPER-2276-01.patch > > > With normal create operation, the path of the failed node is displayed in > KeeperException but this is not the case when create operation is through > multi api -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2496) When inside a transaction, some exceptions do not have path information set.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15518596#comment-15518596 ] Arshad Mohammad commented on ZOOKEEPER-2496: Async multi API does process the result and also it does not throw execption. Result is processed in the callback handler I think the logic to find path of transaction should be written in the callback handler. Any thought? I am just re-basing the ZOOKEEPER-2276 patch > When inside a transaction, some exceptions do not have path information set. > > > Key: ZOOKEEPER-2496 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2496 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 >Reporter: Kazuaki Banzai > Attachments: transactionException.patch > > > If a client tries to execute some illegal operations inside a transaction, > ZooKeeper throws an exception. > Some exceptions such as NodeExistsException should have a path to indicate > where the exception occurred. > ZooKeeper clients can get the path by calling method getPath. > However, this method returns null if the exception occurs inside a > transaction. > For example, when a client calls create /a and create /a in a transaction, > ZooKeeper throws NodeExistsException but getPath returns null. > In normal operation (outside transactions), the path information is set > correctly. > The patch only shows this bug occurs with NoNode exception and NodeExists > exception, > but this bug seems to occur with any exception which needs a path information: > When an error occurred in a transaction, ZooKeeper creates an ErrorResult > instance to represent error result. > However, the ErrorResult class doesn't have a field for a path where an error > occurred(See src/java/main/org/apache/zookeeper/OpResult.java for more > details). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2496) When inside a transaction, some exceptions do not have path information set.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15516289#comment-15516289 ] Arshad Mohammad commented on ZOOKEEPER-2496: Thanks [~kazuakibanzai] for the feeback on ZOOKEEPER-2276. If you have already fixed both scenarios you mentioned I can assign you ZOOKEEPER-2276, may be you can submit patch there or here in this jira. Otherwise i will submit new patch for ZOOKEEPER-2276 soon. > When inside a transaction, some exceptions do not have path information set. > > > Key: ZOOKEEPER-2496 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2496 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 >Reporter: Kazuaki Banzai > Attachments: transactionException.patch > > > If a client tries to execute some illegal operations inside a transaction, > ZooKeeper throws an exception. > Some exceptions such as NodeExistsException should have a path to indicate > where the exception occurred. > ZooKeeper clients can get the path by calling method getPath. > However, this method returns null if the exception occurs inside a > transaction. > For example, when a client calls create /a and create /a in a transaction, > ZooKeeper throws NodeExistsException but getPath returns null. > In normal operation (outside transactions), the path information is set > correctly. > The patch only shows this bug occurs with NoNode exception and NodeExists > exception, > but this bug seems to occur with any exception which needs a path information: > When an error occurred in a transaction, ZooKeeper creates an ErrorResult > instance to represent error result. > However, the ErrorResult class doesn't have a field for a path where an error > occurred(See src/java/main/org/apache/zookeeper/OpResult.java for more > details). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2593) Enforce the quota limit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513419#comment-15513419
]
Arshad Mohammad commented on ZOOKEEPER-2593:
Thanks [~eribeiro]
yes, this is same as ZOOKEEPER-451. But in that JIRA we needs few improvement
# enforce the quota limit at more granular level. can we add
enforce.number.quota and enforce.byte.quota ?
# I think there is need to change the implementation as well.
we should check the limit at centralized place like in {{
PrepRequestProcessor}}.
If we check the limit in DataTree which is at every server then the exceptions
can not be passed to clients.
> Enforce the quota limit
> ---
>
> Key: ZOOKEEPER-2593
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2593
> Project: ZooKeeper
> Issue Type: New Feature
> Components: java client, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>
> Currently in ZooKeeper when quota limit exceeds, a warning is logged. There
> are many user scenarios where it is desired to throw exception in case quota
> limits exceed.
> We should make it configurable whether to throw exception or just log the
> warning when quota limits exceed.
> *Implementation:*
> add new properties
> {code}
> enforce.number.quota
> enforce.byte.quota
> {code}
> add new error codes
> {code}
> KeeperException.Code.NUMBERQUOTAEXCEED
> KeeperException.Code.BYTEQUOTAEXCEED
> {code}
> add new exception
> {code}
> KeeperException.NumberQuotaExceedException
> KeeperException.ByteQuotaExceedException
> {code}
>
> *Basic Scenarios:*
> # If enforce.number.quota=true and number quota exceed, then server should
> send NUMBERQUOTAEXCEED error code and client should throw
> NumberQuotaExceedException
> # If enforce.byte.quota=true and byte quota exceed, then server should send
> BYTEQUOTAEXCEED error code and client should throw ByteQuotaExceedException
> *Impacted APIs:*
> create
> setData
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2580) ErrorMessage is not correct when set IP acl and try to set again from another machine
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512394#comment-15512394 ] Arshad Mohammad commented on ZOOKEEPER-2580: [~rakeshsingh], I thought you are taking about scenario based some critical issue, but yes, I was wrong you were talking message correction related trivial issue only. All the best for your message correction endeavor. > ErrorMessage is not correct when set IP acl and try to set again from another > machine > - > > Key: ZOOKEEPER-2580 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2580 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Priority: Minor > > set IP acl and try to set again from another machine:- > [zk: localhost:2181(CONNECTED) 11] setAcl /ip_test ip:10.18.101.80:crdwa > KeeperErrorCode = NoAuth for /ip_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15512106#comment-15512106 ] Arshad Mohammad commented on ZOOKEEPER-2569: You mean, API should check whether user passed plain password or encrypted password and if it is plain password then it should not accepted? I don't think we should be doing this kind of validation here. > plain password is stored when set individual ACL using digest scheme > > > Key: ZOOKEEPER-2569 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh > > Plain password is stored when set individual ACL using digest scheme instead > of storing the username and encoded hash string of > [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass > [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa > [zk: localhost:2181(CONNECTED) 15] getAcl /newNode > 'digest,'user:pass > : cdrwa > [zk: localhost:2181(CONNECTED) 16] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-2569: --- Comment: was deleted (was: This is discussion only. Conclusion would have been if the issue was closed as not an issue.) > plain password is stored when set individual ACL using digest scheme > > > Key: ZOOKEEPER-2569 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh > > Plain password is stored when set individual ACL using digest scheme instead > of storing the username and encoded hash string of > [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass > [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa > [zk: localhost:2181(CONNECTED) 15] getAcl /newNode > 'digest,'user:pass > : cdrwa > [zk: localhost:2181(CONNECTED) 16] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2570) ZooKeeper clients are timed out when ZooKeeper servers are very busy
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2570:
---
Description:
ZooKeeper clients are timed out when ZooKeeper servers are very busy. Clients
throw below exception and fail all the pending operations
{code}
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss
at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
{code}
Clients log bellow information
{noformat}
2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - WARN
[main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client session
timed out, have not heard from server in 13908ms for sessionid 0x2d21b28
2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - INFO
[main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client session
timed out, have not heard from server in 13908ms for sessionid
0x2d21b28, closing socket connection and attempting reconnect
{noformat}
*STEPS TO REPRODECE:*
# Create multi operation
{code}
List ops = new ArrayList();
for (int i = 0; i < N; i++) {
Op create = Op.create(rootNode + "/" + i, "".getBytes(),
ZooDefs.Ids.OPEN_ACL_UNSAFE,
CreateMode.PERSISTENT);
ops.add(create);
}
{code}
Chose N in such a way that the total multi operation request size is less than
but near 1 MB. For bigger request size increase jute.maxbuffer in servers
# Submit the multi operation request
{code} zooKeeper.multi(ops);{code}
# After repeating above steps few times issue is reproduced
was:
ZooKeeper server expires the client session when server is continuously under
higher load. Below steps can reproduce the issue
# Create multi operation
{code}
List ops = new ArrayList();
for (int i = 0; i < N; i++) {
Op create = Op.create(rootNode + "/" + i, "".getBytes(),
ZooDefs.Ids.OPEN_ACL_UNSAFE,
CreateMode.PERSISTENT);
ops.add(create);
}
{code}
Chose N in such a way that the total multi operation request size is less than
but near 1 MB. For bigger request size increase jute.maxbuffer in servers
# Submit the multi operation request
{code} zooKeeper.multi(ops);{code}
# After repeating above steps few times client throws
{{ConnectionLossException}} and at server one can find log "Expiring session
0x100b0ff5ecc0003, timeout of ms exceeded"
Normally server expires session when it is not receiving ping from the client
for longer than the client's session time-out. But in this case client is
continuously doing operation with the server. So server should not expire the
session.
> ZooKeeper clients are timed out when ZooKeeper servers are very busy
>
>
> Key: ZOOKEEPER-2570
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2570
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
>
> ZooKeeper clients are timed out when ZooKeeper servers are very busy. Clients
> throw below exception and fail all the pending operations
> {code}
> org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode
> = ConnectionLoss
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
> {code}
> Clients log bellow information
> {noformat}
> 2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - WARN
> [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1181] - Client
> session timed out, have not heard from server in 13908ms for sessionid
> 0x2d21b28
> 2016-09-22 01:49:08,001 [myid:127.0.0.1:11228] - INFO
> [main-SendThread(127.0.0.1:11228):ClientCnxn$SendThread@1229] - Client
> session timed out, have not heard from server in 13908ms for sessionid
> 0x2d21b28, closing socket connection and attempting reconnect
> {noformat}
> *STEPS TO REPRODECE:*
> # Create multi operation
> {code}
> List ops = new ArrayList();
> for (int i = 0; i < N; i++) {
> Op create = Op.create(rootNode + "/" + i, "".getBytes(),
> ZooDefs.Ids.OPEN_ACL_UNSAFE,
> CreateMode.PERSISTENT);
> ops.add(create);
> }
> {code}
> Chose N in such a way that the total multi operation request size is less
> than but near 1 MB. For bigger request size increase jute.maxbuffer in
> servers
> # Submit the multi operation request
> {code} zooKeeper.multi(ops);{code}
> # After repeating above steps few times issue is reproduced
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2570) ZooKeeper clients are timed out when ZooKeeper servers are very busy
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2570:
---
Summary: ZooKeeper clients are timed out when ZooKeeper servers are very
busy (was: ZooKeeper server expires the client session when server is
continuously under higher load)
> ZooKeeper clients are timed out when ZooKeeper servers are very busy
>
>
> Key: ZOOKEEPER-2570
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2570
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
>
> ZooKeeper server expires the client session when server is continuously under
> higher load. Below steps can reproduce the issue
> # Create multi operation
> {code}
> List ops = new ArrayList();
> for (int i = 0; i < N; i++) {
> Op create = Op.create(rootNode + "/" + i, "".getBytes(),
> ZooDefs.Ids.OPEN_ACL_UNSAFE,
> CreateMode.PERSISTENT);
> ops.add(create);
> }
> {code}
> Chose N in such a way that the total multi operation request size is less
> than but near 1 MB. For bigger request size increase jute.maxbuffer in
> servers
> # Submit the multi operation request
> {code} zooKeeper.multi(ops);{code}
> # After repeating above steps few times client throws
> {{ConnectionLossException}} and at server one can find log "Expiring
> session 0x100b0ff5ecc0003, timeout of ms exceeded"
> Normally server expires session when it is not receiving ping from the client
> for longer than the client's session time-out. But in this case client is
> continuously doing operation with the server. So server should not expire
> the session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2585) ACL with SSL is not working
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509252#comment-15509252 ] Arshad Mohammad commented on ZOOKEEPER-2585: # Thanks [~rakeshsingh] for the advice. These are my opinion based on technical facts and these are not conclusions. If it was concluded it would have been closed as not an issue. # bq. In this issue pls try to perform the steps mentioned here in 2 case- one when zookeeper started in ssl mode and another when zookeeper started in non-ssl mode and will get the difference I think this is something new you are taking about. It is not mentioned in the defect description. In the defect description only SSL enabled standalone server is mentioned. # sure, we can discuss for clarity. Which step you performed on non SSL server > ACL with SSL is not working > --- > > Key: ZOOKEEPER-2585 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2585 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Priority: Critical > > Set ACL with SSL is not working > Steps to reproduce:- > 1. Start zookeeper in ssl mode in standalone > 2. Connect zookeeper from zookeeper client (using zkCli.sh) > 3. add auth and set ACL as below and then quit the client :- > [zk: localhost:2181(CONNECTED) 0] addauth digest u1:p1 > [zk: localhost:2181(CONNECTED) 1] create /test_auth hello > Created /test_auth > [zk: localhost:2181(CONNECTED) 2] setAcl /test_auth auth:u1:p1:crdwa > [zk: localhost:2181(CONNECTED) 3] get /test_auth > hello > [zk: localhost:2181(CONNECTED) 4] quit > 4. Connect again zookeeper from zookeeper client (using zkCli.sh) > 5. Try to access the znode, try to set the data and so on, everything is > allowed > [zk: localhost:2181(CONNECTED) 2] set /test_auth hello1 > [zk: localhost:2181(CONNECTED) 3] get /test_auth > hello1 > [zk: localhost:2181(CONNECTED) 1] getAcl /test_auth > 'x509,'CN=locahost%2COU=CS%2CO=HUAWEI%2CL=Shenzhen%2CST=Guangdong%2CC=CHINA > : cdrwa > 'digest,'u1:fpT/y03U+EjItKZOSLGvjnJlyng= > : cdrwa -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508904#comment-15508904 ] Arshad Mohammad commented on ZOOKEEPER-2569: [~rakeshsingh], That was my opinion and I can be very much wrong. Why you take those comments as conclusion. Those comments are the discussion only. It would have been conclusion if the issue was closed as not an issue. Lets listen some more opinion to really conclude it :-) > plain password is stored when set individual ACL using digest scheme > > > Key: ZOOKEEPER-2569 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh > > Plain password is stored when set individual ACL using digest scheme instead > of storing the username and encoded hash string of > [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass > [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa > [zk: localhost:2181(CONNECTED) 15] getAcl /newNode > 'digest,'user:pass > : cdrwa > [zk: localhost:2181(CONNECTED) 16] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508864#comment-15508864 ] Arshad Mohammad commented on ZOOKEEPER-2569: This is discussion only. Conclusion would have been if the issue was closed as not an issue. > plain password is stored when set individual ACL using digest scheme > > > Key: ZOOKEEPER-2569 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh > > Plain password is stored when set individual ACL using digest scheme instead > of storing the username and encoded hash string of > [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass > [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa > [zk: localhost:2181(CONNECTED) 15] getAcl /newNode > 'digest,'user:pass > : cdrwa > [zk: localhost:2181(CONNECTED) 16] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2567) Error message is not correct when wrong argument is passed for "reconfig" cmd
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507651#comment-15507651 ] Arshad Mohammad commented on ZOOKEEPER-2567: What message you are expecting? Can you suggest some message? > Error message is not correct when wrong argument is passed for "reconfig" cmd > - > > Key: ZOOKEEPER-2567 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2567 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Reporter: Rakesh Kumar Singh >Priority: Minor > > Error message is not correct when wrong argument is passed for "reconfig" cmd > Steps to reproduce:- > 1. Start zookeeper in cluster mode > 2. use reconfig cmd with wrong argument (pass : instead of ;) > [zk: localhost:2181(CONNECTED) 10] reconfig -remove 3 -add > 3=10.18.221.194:2888:3888:2181 > KeeperErrorCode = BadArguments for > Here error message is not complete and informative on client console. > The log is as below:- > 2016-09-08 18:54:08,701 [myid:1] - INFO [ProcessThread(sid:1 > cport:-1)::PrepRequestProcessor@512] - Incremental reconfig > 2016-09-08 18:54:08,702 [myid:1] - INFO [ProcessThread(sid:1 > cport:-1)::PrepRequestProcessor@843] - Got user-level KeeperException when > processing sessionid:0x100299b7eac type:reconfig cxid:0x7 > zxid:0x40004 txntype:-1 reqpath:n/a Error Path:Reconfiguration failed > Error:KeeperErrorCode = BadArguments for Reconfiguration failed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507619#comment-15507619
]
Arshad Mohammad edited comment on ZOOKEEPER-2569 at 9/20/16 7:57 PM:
-
This is not a problem.
bq. \[zk: localhost:2181(CONNECTED) 14\] setAcl /newNode digest:user:pass:crdwa
This step is wrong. To authorize user:pass id you should set the acl as
{{setAcl /newNode digest:user:smGaoVKd/cQkjm7b88GyorAUz20=:crdwa}}. So there is
no plain password here.
was (Author: arshad.mohammad):
This is not a prolem.
bq. \[zk: localhost:2181(CONNECTED) 14\] setAcl /newNode digest:user:pass:crdwa
This step is wrong. To authorize user:pass id you should set the acl as
{{setAcl /newNode digest:user:smGaoVKd/cQkjm7b88GyorAUz20=:crdwa}}. So there is
no plain password here.
> plain password is stored when set individual ACL using digest scheme
>
>
> Key: ZOOKEEPER-2569
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569
> Project: ZooKeeper
> Issue Type: Bug
> Components: security
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>
> Plain password is stored when set individual ACL using digest scheme instead
> of storing the username and encoded hash string of
> [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass
> [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa
> [zk: localhost:2181(CONNECTED) 15] getAcl /newNode
> 'digest,'user:pass
> : cdrwa
> [zk: localhost:2181(CONNECTED) 16]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2569) plain password is stored when set individual ACL using digest scheme
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507619#comment-15507619
]
Arshad Mohammad commented on ZOOKEEPER-2569:
This is not a prolem.
bq. \[zk: localhost:2181(CONNECTED) 14\] setAcl /newNode digest:user:pass:crdwa
This step is wrong. To authorize user:pass id you should set the acl as
{{setAcl /newNode digest:user:smGaoVKd/cQkjm7b88GyorAUz20=:crdwa}}. So there is
no plain password here.
> plain password is stored when set individual ACL using digest scheme
>
>
> Key: ZOOKEEPER-2569
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2569
> Project: ZooKeeper
> Issue Type: Bug
> Components: security
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>
> Plain password is stored when set individual ACL using digest scheme instead
> of storing the username and encoded hash string of
> [zk: localhost:2181(CONNECTED) 13] addauth digest user:pass
> [zk: localhost:2181(CONNECTED) 14] setAcl /newNode digest:user:pass:crdwa
> [zk: localhost:2181(CONNECTED) 15] getAcl /newNode
> 'digest,'user:pass
> : cdrwa
> [zk: localhost:2181(CONNECTED) 16]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2580) ErrorMessage is not correct when set IP acl and try to set again from another machine
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507592#comment-15507592 ] Arshad Mohammad commented on ZOOKEEPER-2580: This is not a problem. Suppose you are at machine-1 and you set ACL crdwa for machine-2 then of course you have to log-in from machine-2 to change the ACL I think you are not machine-2 and trying to change the ACL. isn't it? > ErrorMessage is not correct when set IP acl and try to set again from another > machine > - > > Key: ZOOKEEPER-2580 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2580 > Project: ZooKeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Priority: Minor > > set IP acl and try to set again from another machine:- > [zk: localhost:2181(CONNECTED) 11] setAcl /ip_test ip:10.18.101.80:crdwa > KeeperErrorCode = NoAuth for /ip_test -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2582) When addauth twice for same user but different password, it is adding 2 digest corresponding to both username, password and so we can able to access znode with user
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507546#comment-15507546 ] Arshad Mohammad commented on ZOOKEEPER-2582: # This is not a problem. # In digest authentication scheme user alone is not the id. Both user and password form the id. so user1:pass1 and user1:pass are two different ids # bq. addauth digest user1:, we can able to access the znode. This is because both the ids, user1:pass1 and user1:pass, are given permission. This is done when you set the ACLs using the auth scheme. For detail refer my comment in ZOOKEEPER-2585. > When addauth twice for same user but different password, it is adding 2 > digest corresponding to both username, password and so we can able to access > znode with user and any of these password which does not seem to be correct > > > Key: ZOOKEEPER-2582 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2582 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh > > When addauth twice for same user but different password, it is adding 2 > digest corresponding to both username, password and so we can able to access > znode with user and any of these password which does not seem to be correct > Steps:- > [zk: localhost:2181(CONNECTED) 0] addauth digest user1:pass1 > [zk: localhost:2181(CONNECTED) 1] addauth digest user1:pass > [zk: localhost:2181(CONNECTED) 9] create /user_test5 hello > Created /user_test5 > [zk: localhost:2181(CONNECTED) 10] setAcl /user_test5 auth:user1:pass1:crdwa > [zk: localhost:2181(CONNECTED) 11] getAcl /user_test5 > 'digest,'user1:+7K83PhyQ3ijGj0ADmljf0quVwQ= > : cdrwa > 'digest,'user1:UZIsvOKp29j8vAahJzjgpA1VTOk= > : cdrwa > Here we can see 2 entries for same user (user1) with different password > Now disconnect the client and connect again using zkCli.sh > addauth digest user1:, we can able to access the znode. > [zk: localhost:2181(CONNECTED) 0] get /user_test5 > Authentication is not valid : /user_test5 > [zk: localhost:2181(CONNECTED) 1] addauth digest user1:pass > [zk: localhost:2181(CONNECTED) 2] get /user_test5 > hello > Same way, it will allow n number of entry if we addauth for same user with n > number of password -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2585) ACL with SSL is not working
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507488#comment-15507488
]
Arshad Mohammad commented on ZOOKEEPER-2585:
# This is not a problem, this is the expected behavior
# auth ACL scheme adds ACLs for authorized ids in the session. auth ACL scheme
means add ACLs for authorized ids. In your case there were two authorized ids
when you executed {{setAcl /test_auth auth:u1:p1:crdwa}}
'x509,'CN=locahost%2COU=CS%2CO=HUAWEI%2CL=Shenzhen%2CST=Guangdong%2CC=CHINA and
digest,'u1:fpT/y03U+EjItKZOSLGvjnJlyng=
So the ACLs are added for these two ids.
# In {{setAcl /test_auth auth:u1:p1:crdwa}} command u1:p1 are meaning less and
are completely ignored. I don't know why these are mandatory to pass from CLI.
May be you can raise JIRA for this.
# When you logged-in after quit, the
'x509,'CN=locahost%2COU=CS%2CO=HUAWEI%2CL=Shenzhen%2CST=Guangdong%2CC=CHINA got
added as authorized id again. Because this id has all the permissions on on
/test_auth node, you are able to perform all the operations.
> ACL with SSL is not working
> ---
>
> Key: ZOOKEEPER-2585
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2585
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>Priority: Critical
>
> Set ACL with SSL is not working
> Steps to reproduce:-
> 1. Start zookeeper in ssl mode in standalone
> 2. Connect zookeeper from zookeeper client (using zkCli.sh)
> 3. add auth and set ACL as below and then quit the client :-
> [zk: localhost:2181(CONNECTED) 0] addauth digest u1:p1
> [zk: localhost:2181(CONNECTED) 1] create /test_auth hello
> Created /test_auth
> [zk: localhost:2181(CONNECTED) 2] setAcl /test_auth auth:u1:p1:crdwa
> [zk: localhost:2181(CONNECTED) 3] get /test_auth
> hello
> [zk: localhost:2181(CONNECTED) 4] quit
> 4. Connect again zookeeper from zookeeper client (using zkCli.sh)
> 5. Try to access the znode, try to set the data and so on, everything is
> allowed
> [zk: localhost:2181(CONNECTED) 2] set /test_auth hello1
> [zk: localhost:2181(CONNECTED) 3] get /test_auth
> hello1
> [zk: localhost:2181(CONNECTED) 1] getAcl /test_auth
> 'x509,'CN=locahost%2COU=CS%2CO=HUAWEI%2CL=Shenzhen%2CST=Guangdong%2CC=CHINA
> : cdrwa
> 'digest,'u1:fpT/y03U+EjItKZOSLGvjnJlyng=
> : cdrwa
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2589) Not able to access znode if IP ACL is set on a znode when zookeeper started in ssl mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507142#comment-15507142 ] Arshad Mohammad commented on ZOOKEEPER-2589: Theoretically, the reason for this problem is same as the ZOOKEEPER-2547. As you have enabled the SSL, you must have configured serverCnxnFactory= org.apache.zookeeper.server.NettyServerCnxnFactory in server. NettyServerCnxnFactory is not adding the client IP as authorized ip which leads to this problem. May be, you can take ZOOKEEPER-2547 latest patch, verify it and give feedback here. > 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-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504491#comment-15504491 ] Arshad Mohammad commented on ZOOKEEPER-2521: as [~abrahamfine] already said, It is quite possible that a password may start with white space or end with white space. Also, space truncating should be done in the cases where we are sure about the values like paths, true, false, integer values etc. I think in this case truncating the space is not required at all. > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Attachments: ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2551) Remove Hadoop Logo from ZooKeeper documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504413#comment-15504413 ] Arshad Mohammad commented on ZOOKEEPER-2551: Some binary files are added and modified so it is expected that CI check will fail. Patch can not be applied. Following are done in the patch ZOOKEEPER-2551-01.patch # removed hadoop-logo.jpg from src/docs/src/documentation/resources/images and generated doc location docs/images/ # Changed the group project from hadoop to apache # downloaded http://apache.org/images/feather-small.gif added it to src/docs/src/documentation/resources/images folder. After document generation same file will go in docs/images folder as well and it should be checked-in there. > Remove Hadoop Logo from ZooKeeper documentation > --- > > Key: ZOOKEEPER-2551 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2551 > Project: ZooKeeper > Issue Type: Bug > Components: documentation >Reporter: Arshad Mohammad >Assignee: Arshad Mohammad > Fix For: 3.5.3 > > Attachments: ZOOKEEPER-2551-01.patch > > > ZooKeeper documentation has hadoop logo on each page's header. There is no > significance to put the hadoop logo on ZooKeeper project. So hadoop logo > should be removed from Zookeeper as ZooKeeper is independent of hadoop > project, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2551) Remove Hadoop Logo from ZooKeeper documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-2551: --- Attachment: ZOOKEEPER-2551-01.patch > Remove Hadoop Logo from ZooKeeper documentation > --- > > Key: ZOOKEEPER-2551 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2551 > Project: ZooKeeper > Issue Type: Bug > Components: documentation >Reporter: Arshad Mohammad >Assignee: Arshad Mohammad > Fix For: 3.5.3 > > Attachments: ZOOKEEPER-2551-01.patch > > > ZooKeeper documentation has hadoop logo on each page's header. There is no > significance to put the hadoop logo on ZooKeeper project. So hadoop logo > should be removed from Zookeeper as ZooKeeper is independent of hadoop > project, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2593) Enforce the quota limit
Arshad Mohammad created ZOOKEEPER-2593:
--
Summary: Enforce the quota limit
Key: ZOOKEEPER-2593
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2593
Project: ZooKeeper
Issue Type: New Feature
Components: java client, server
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
Currently in ZooKeeper when quota limit exceeds, a warning is logged. There are
many user scenarios where it is desired to throw exception in case quota limits
exceed.
We should make it configurable whether to throw exception or just log the
warning when quota limits exceed.
*Implementation:*
add new properties
{code}
enforce.number.quota
enforce.byte.quota
{code}
add new error codes
{code}
KeeperException.Code.NUMBERQUOTAEXCEED
KeeperException.Code.BYTEQUOTAEXCEED
{code}
add new exception
{code}
KeeperException.NumberQuotaExceedException
KeeperException.ByteQuotaExceedException
{code}
*Basic Scenarios:*
# If enforce.number.quota=true and number quota exceed, then server should send
NUMBERQUOTAEXCEED error code and client should throw NumberQuotaExceedException
# If enforce.byte.quota=true and byte quota exceed, then server should send
BYTEQUOTAEXCEED error code and client should throw ByteQuotaExceedException
*Impacted APIs:*
create
setData
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
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] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
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-1971) Make JMX remote monitoring port configurable
[ 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
[ 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)
[jira] [Updated] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[ 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] [Updated] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[ 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] [Updated] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[ 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
[ 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)
[jira] [Commented] (ZOOKEEPER-1078) add maven build support to ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15493359#comment-15493359 ] Arshad Mohammad commented on ZOOKEEPER-1078: These dependencies were upgraded recently and the latest patch is little older you can update the dependency to make it work. I will take care in the next patch > add maven build support to ZooKeeper > > > Key: ZOOKEEPER-1078 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1078 > Project: ZooKeeper > Issue Type: Improvement > Components: build >Reporter: Patrick Hunt >Assignee: Arshad Mohammad > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-1078-04.patch, ZOOKEEPER-1078-05.patch, > ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch, ZOOKEEPER-1078.patch > > > I've taken a stab at creating a maven build for ZooKeeper. (attachment to > follow). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2172) Cluster crashes when reconfig a new node as a participant
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492587#comment-15492587 ] Arshad Mohammad commented on ZOOKEEPER-2172: Thanks [~Bhupendra], [~ajithshetty] for helping me in analysing this issue. Thanks [~shralex],[~phunt] for reviewing and committing the patch. Thanks every one for participating in the discussion and providing useful information. > Cluster crashes when reconfig a new node as a participant > - > > Key: ZOOKEEPER-2172 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2172 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection, quorum, server >Affects Versions: 3.5.0 > Environment: Ubuntu 12.04 + java 7 >Reporter: Ziyou Wang >Assignee: Arshad Mohammad >Priority: Critical > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2172-02.patch, ZOOKEEPER-2172-03.patch, > ZOOKEEPER-2172-04.patch, ZOOKEEPER-2172-06.patch, ZOOKEEPER-2172-07.patch, > ZOOKEEPER-2172.patch, ZOOKEPER-2172-05.patch, history.txt, node-1.log, > node-2.log, node-3.log, zoo-1.log, zoo-2-1.log, zoo-2-2.log, zoo-2-3.log, > zoo-2.log, zoo-2212-1.log, zoo-2212-2.log, zoo-2212-3.log, zoo-3-1.log, > zoo-3-2.log, zoo-3-3.log, zoo-3.log, zoo-4-1.log, zoo-4-2.log, zoo-4-3.log, > zoo.cfg.dynamic.1005d, zoo.cfg.dynamic.next, zookeeper-1.log, > zookeeper-1.out, zookeeper-2.log, zookeeper-2.out, zookeeper-3.log, > zookeeper-3.out > > > The operations are quite simple: start three zk servers one by one, then > reconfig the cluster to add the new one as a participant. When I add the > third one, the zk cluster may enter a weird state and cannot recover. > > I found “2015-04-20 12:53:48,236 [myid:1] - INFO [ProcessThread(sid:1 > cport:-1)::PrepRequestProcessor@547] - Incremental reconfig” in node-1 log. > So the first node received the reconfig cmd at 12:53:48. Latter, it logged > “2015-04-20 12:53:52,230 [myid:1] - ERROR > [LearnerHandler-/10.0.0.2:55890:LearnerHandler@580] - Unexpected exception > causing shutdown while sock still open” and “2015-04-20 12:53:52,231 [myid:1] > - WARN [LearnerHandler-/10.0.0.2:55890:LearnerHandler@595] - *** GOODBYE > /10.0.0.2:55890 ”. From then on, the first node and second node > rejected all client connections and the third node didn’t join the cluster as > a participant. The whole cluster was done. > > When the problem happened, all three nodes just used the same dynamic > config file zoo.cfg.dynamic.1005d which only contained the first two > nodes. But there was another unused dynamic config file in node-1 directory > zoo.cfg.dynamic.next which already contained three nodes. > > When I extended the waiting time between starting the third node and > reconfiguring the cluster, the problem didn’t show again. So it should be a > race condition problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491473#comment-15491473
]
Arshad Mohammad commented on ZOOKEEPER-2573:
revision gives very good information in analyzing whether a particular fix
included in the build, specially in private builds. If we have option to remove
this , we definitely have option to change it. I think it is better to change
{{org.apache.zookeeper.version.Info.REVISION}} from int to String and store the
git revision.
[~phunt] shall I submit the patch for this?
> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
> Issue Type: Bug
> Components: build, server
>Reporter: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be
> modified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1971) Make JMX remote monitoring port configurable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491433#comment-15491433 ] Arshad Mohammad commented on ZOOKEEPER-1971: If we throw exception many exiting zookeeper applications start failing because of port conflict. Exception was not thrown to make the existing applications work as before. But there are many other problem with this approach even the normal jmx env is not started. I will disable custom jxm by default in the code, but enable custom jmx from zkServer.sh by default then we can throw exception in case of the custom jxm env fails. I will update the patch for this. > 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, > 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
[ 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-02.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, > 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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491319#comment-15491319
]
Arshad Mohammad commented on ZOOKEEPER-1971:
Thanks [~phunt] for the feedback
There is two reasons current patch is not working with JMXSSL=true
1)There is a problem in the code
2) Some more configurations are required,in addition to what you already
configured.
Submitting new patch to fix the 1) problem.
After this new patch following configurations worked for me.
{noformat}
configured rmi.connector.port=6615 in zoo.cfg
added following in zkEnv.sh
SERVER_JVMFLAGS="$SERVER_JVMFLAGS
-Djavax.net.ssl.keyStore=/home/sage/resources/common/keystore"
SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Djavax.net.ssl.keyStorePassword=mypass"
SERVER_JVMFLAGS="$SERVER_JVMFLAGS
-Djavax.net.ssl.trustStore=/home/sage/resources/common/keystore"
SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Djavax.net.ssl.trustStorePassword=mypass"
export SERVER_JVMFLAGS=$SERVER_JVMFLAGS
export JMXSSL=true
export JMXPORT="6610"
Connected from JConsole:
jconsole -J-Djavax.net.ssl.trustStore=D:/workspace/ssl/keystore
-J-Djavax.net.ssl.trustStorePassword=mypass
{noformat}
> 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, 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-2517) jute.maxbuffer is ignored
[
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-03.patch
> 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.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-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15491284#comment-15491284
]
Arshad Mohammad commented on ZOOKEEPER-2517:
Thanks [~fpj] for reviews.
# I was using maximum line width 120 in eclipse. now changed to 80 and
formatted the modified code. is this OK? or is there any other zookeeper
guideline for this.
# Throwing NumberFormatException from ZKConfig.getInt(String, int).
# bq. If we propagate the exception, then it should end up caught in
zookeeper.getClientCnxnSocket and transformed into an IOException
can we log the warning here and use the default value?
> 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.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-2574) PurgeTxnLog can inadvertently delete required txn log files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15482179#comment-15482179 ] Arshad Mohammad commented on ZOOKEEPER-2574: Latest patch LGTM +1(non-binding) > PurgeTxnLog can inadvertently delete required txn log files > --- > > Key: ZOOKEEPER-2574 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2574 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.7, 3.4.8, 3.5.0, 3.5.1, 3.5.2 > Environment: Zookeeper 3.4.8, standalone, and 3-server quorum >Reporter: Abhishek Rai >Assignee: Abhishek Rai >Priority: Blocker > Fix For: 3.4.10, 3.5.3 > > Attachments: ZOOKEEPER-2574.2.patch, ZOOKEEPER-2574.3.patch, > ZOOKEEPER-2574.patch > > > As part of the fix for ZOOKEEPER-1797, the call to > FileTxnSnapLog.getSnapshotLogs() was removed from PurgeTxnLog.java. As a > result, some old-looking but required txn log files can be deleted, resulting > in data corruption or loss. > For example, consider the following: > 1. Configuration: > autopurge.snapRetainCount=3 > 2. Following files exist: > log.100 spans transactions from zxid=100 till zxid=140 (inclusive) > snapshot.110 - snapshot as of zxid=110 > snapshot.120 - snapshot as of zxid=120 > snapshot.130 - snapshot as of zxid=130 > Above scenario is possible when snapshotting has happened multiple times but > without accompanying log rollover, which is possible if the server was > running as a learner. > 3. PurgeTxnLog retains all snapshots but deletes log.100 because its zxid is > older than the zxid of the oldest snapshot (110). This results in loss of > transactions in the range 131-140. > Before the fix for ZOOKEEPER-1797, this was avoided by the call to > FileTxnSnapLog.getSnapshotLogs() which finds and retains the newest txn log > file with starting zxid < oldest retained snapshot's highest zxid. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2574) PurgeTxnLog can inadvertently delete required txn log files
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15481700#comment-15481700
]
Arshad Mohammad commented on ZOOKEEPER-2574:
Thanks [~abhishekrai] for working on this issue.
The solution looks good to me. I can see FileTxnLog.getLogFiles has the logic
to retain highest transaction log which is less than the leastZxidToBeRetain.
Few comments
1) can we rename exclude to retainedTxnLogs or some thing similar.
{code}
final Set exclude = new HashSet();
{code}
2) FileTxnSnapLog.getSnapshotLogs(long) javadoc does not have complete
information.
can you update it to indicate that it also returns "one snapshot log which is
highest but less than the given zxid"
> PurgeTxnLog can inadvertently delete required txn log files
> ---
>
> Key: ZOOKEEPER-2574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2574
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.7, 3.4.8, 3.5.0, 3.5.1, 3.5.2
> Environment: Zookeeper 3.4.8, standalone, and 3-server quorum
>Reporter: Abhishek Rai
>Assignee: Abhishek Rai
>Priority: Blocker
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2574.2.patch, ZOOKEEPER-2574.patch
>
>
> As part of the fix for ZOOKEEPER-1797, the call to
> FileTxnSnapLog.getSnapshotLogs() was removed from PurgeTxnLog.java. As a
> result, some old-looking but required txn log files can be deleted, resulting
> in data corruption or loss.
> For example, consider the following:
> 1. Configuration:
> autopurge.snapRetainCount=3
> 2. Following files exist:
> log.100 spans transactions from zxid=100 till zxid=140 (inclusive)
> snapshot.110 - snapshot as of zxid=110
> snapshot.120 - snapshot as of zxid=120
> snapshot.130 - snapshot as of zxid=130
> Above scenario is possible when snapshotting has happened multiple times but
> without accompanying log rollover, which is possible if the server was
> running as a learner.
> 3. PurgeTxnLog retains all snapshots but deletes log.100 because its zxid is
> older than the zxid of the oldest snapshot (110). This results in loss of
> transactions in the range 131-140.
> Before the fix for ZOOKEEPER-1797, this was avoided by the call to
> FileTxnSnapLog.getSnapshotLogs() which finds and retains the newest txn log
> file with starting zxid < oldest retained snapshot's highest zxid.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15477401#comment-15477401
]
Arshad Mohammad commented on ZOOKEEPER-2547:
Thanks [~eribeiro] for reviewing the patch.
# I think the diamond operator is only for saving few key strokes. is there any
other advantage?
# We are running the server on 127.0.0.1. The result of
{{InetAddress.getLocalHost().getAddress().toString()}} will be different in
different environment. So can not use
InetAddress.getLocalHost().getAddress().toString()
# The added test case is testing both Netty and NIO.
NIO passes before and after the fix
Netty fails before the fix but passed after the fix.
so no change in the current patch. please let me know if i am missing something
> 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
>
>
> 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-2573) Modify Info.REVISION to adapt git repo
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15477313#comment-15477313
]
Arshad Mohammad commented on ZOOKEEPER-2573:
# shall we modify {{org.apache.zookeeper.version.Info.REVISION}} from int to
String and store the git revision in it
or introduce new variable {{org.apache.zookeeper.version.Info.GIT_REVISION}}
for git revision?
# I would prefer to modify it from int to String, if there is no backward
compatibility concern. It is not an exposed interface, so backward
compatibility should be a concern here.
Any thoughts ?
> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
> Issue Type: Bug
> Components: build, server
>Reporter: Arshad Mohammad
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be
> modified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2573:
---
Fix Version/s: 3.6.0
3.5.3
> Modify Info.REVISION to adapt git repo
> --
>
> Key: ZOOKEEPER-2573
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
> Project: ZooKeeper
> Issue Type: Bug
> Components: build, server
>Reporter: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
>
> Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo
> revision
> Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo
> revision which is of type int
> But after migrating to git repo the git repo's revision(commit
> 63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
> So either we should modify this variable to string to introduce new variable
> to store the git revision and leave the svn revision variable unchanged.
> build.xml, and org.apache.zookeeper.version.util.VerGen also need to be
> modified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo
Arshad Mohammad created ZOOKEEPER-2573:
--
Summary: Modify Info.REVISION to adapt git repo
Key: ZOOKEEPER-2573
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2573
Project: ZooKeeper
Issue Type: Bug
Components: build, server
Reporter: Arshad Mohammad
Modify {{org.apache.zookeeper.version.Info.REVISION}} to store git repo revision
Currently {{org.apache.zookeeper.version.Info.REVISION}} stores the svn repo
revision which is of type int
But after migrating to git repo the git repo's revision(commit
63f5132716c08b3d8f18993bf98eb46eb42f80fb) can not be stored in this variable.
So either we should modify this variable to string to introduce new variable to
store the git revision and leave the svn revision variable unchanged.
build.xml, and org.apache.zookeeper.version.util.VerGen also need to be
modified.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2570) ZooKeeper server expires the client session when server is continuously under higher load
Arshad Mohammad created ZOOKEEPER-2570:
--
Summary: ZooKeeper server expires the client session when server
is continuously under higher load
Key: ZOOKEEPER-2570
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2570
Project: ZooKeeper
Issue Type: Bug
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
Priority: Critical
ZooKeeper server expires the client session when server is continuously under
higher load. Below steps can reproduce the issue
# Create multi operation
{code}
List ops = new ArrayList();
for (int i = 0; i < N; i++) {
Op create = Op.create(rootNode + "/" + i, "".getBytes(),
ZooDefs.Ids.OPEN_ACL_UNSAFE,
CreateMode.PERSISTENT);
ops.add(create);
}
{code}
Chose N in such a way that the total multi operation request size is less than
but near 1 MB. For bigger request size increase jute.maxbuffer in servers
# Submit the multi operation request
{code} zooKeeper.multi(ops);{code}
# After repeating above steps few times client throws
{{ConnectionLossException}} and at server one can find log "Expiring session
0x100b0ff5ecc0003, timeout of ms exceeded"
Normally server expires session when it is not receiving ping from the client
for longer than the client's session time-out. But in this case client is
continuously doing operation with the server. So server should not expire the
session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
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-02.patch
> 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.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-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15473148#comment-15473148
]
Arshad Mohammad commented on ZOOKEEPER-2517:
Thanks [~eribeiro], Handled review comments, please have a look
# instead of just checking trimmed value length, we should use the trimmed
value. Not checking length after trim to log the warning
# getInt is a common class. The classes using it will log the returned value.
If it was a method meant to be used in specific class, no doubt it would have
been a WARN. no problem, changing to WARN
# Because getInt is a small method and I was testing the complete getInt method
but it can be renamed to testIntegerRetrievalFromProperty]Handled review
comments, please have a look.
> 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.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-2554) reconfig can not add new server as observer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15468121#comment-15468121
]
Arshad Mohammad commented on ZOOKEEPER-2554:
It is fine. Thanks [~shralex].
> reconfig can not add new server as observer
> ---
>
> Key: ZOOKEEPER-2554
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.5.1, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ReconfigObserverTest.java, ZOOKEEPER-2554-01.patch
>
>
> Try to add new observer server using reconfig API, server gets added as
> participant.
> STEPS:
> # create 3 node cluster.
> {code}
> server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
> server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> {code}
> # Suppose the 2 is the leader in the above cluster. Configure the new server
> as
> {code}
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
> {code}
> # Connect to 1 and execute the reconfig command
> {code}
> zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
> null, null, -1, null, null);
> {code}
> # Verify sever 3. It was supposed to run as observer but it is running as
> participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2554) reconfig can not add new server as observer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15466241#comment-15466241
]
Arshad Mohammad commented on ZOOKEEPER-2554:
# bq. any server not currently in the view should be a non-voting participant.
AFAIK, non-voting participant means observer but in the code observer is
changed to participant(voting-participant). So code is doing just opposite of
what is intended, isn't it
# Test case is testing the way new observer should get added. It is not
testing the way it is getting added
For observer, server 3, the type changes multiple times: OBSERVER
-->PARTICIPANT -->OBSERVER
## initialized from configuration
{code}
2016-09-06 07:43:31,783 [myid:3] - INFO [Thread-7:QuorumPeer@415] - learner
type set to OBSERVER
java.lang.Exception: exceptionForStackTrace
at
org.apache.zookeeper.server.quorum.QuorumPeer.setLearnerType(QuorumPeer.java:416)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:179)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:120)
at
org.apache.zookeeper.server.quorum.QuorumPeerTestBase$MainThread.run(QuorumPeerTestBase.java:245)
{code}
## updated during first leader election
{code}
2016-09-06 07:43:31,808 [myid:3] - INFO
[WorkerReceiver[myid=3]:QuorumPeer@415] - learner type set to PARTICIPANT
java.lang.Exception: exceptionForStackTrace
at
org.apache.zookeeper.server.quorum.QuorumPeer.setLearnerType(QuorumPeer.java:416)
at
org.apache.zookeeper.server.quorum.QuorumPeer.updateLearnerType(QuorumPeer.java:1843)
at
org.apache.zookeeper.server.quorum.QuorumPeer.processReconfig(QuorumPeer.java:1762)
at
org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerReceiver.run(FastLeaderElection.java:299)
at java.lang.Thread.run(Thread.java:745)
{code}
## During reconfig processing
{code}
2016-09-06 07:43:32,155 [myid:3] - INFO
[QuorumPeer[myid=3](plain=/127.0.0.1:11231)(secure=disabled):QuorumPeer@415] -
learner type set to OBSERVER
java.lang.Exception: exceptionForStackTrace
at
org.apache.zookeeper.server.quorum.QuorumPeer.setLearnerType(QuorumPeer.java:416)
at
org.apache.zookeeper.server.quorum.QuorumPeer.updateLearnerType(QuorumPeer.java:1824)
at
org.apache.zookeeper.server.quorum.QuorumPeer.processReconfig(QuorumPeer.java:1762)
at
org.apache.zookeeper.server.quorum.Follower.processPacket(Follower.java:151)
at
org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:90)
at
org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1113)
{code}
## In reconfig when type is changed from PARTICIPANT to OBSERVER, it is major
change and exception is thrown and leader election happens again.
# So overall procedure to add the observer becomes very lengthy unnecessarily.
is the expected way to add observers?
> reconfig can not add new server as observer
> ---
>
> Key: ZOOKEEPER-2554
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.5.1, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ReconfigObserverTest.java, ZOOKEEPER-2554-01.patch
>
>
> Try to add new observer server using reconfig API, server gets added as
> participant.
> STEPS:
> # create 3 node cluster.
> {code}
> server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
> server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> {code}
> # Suppose the 2 is the leader in the above cluster. Configure the new server
> as
> {code}
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
> {code}
> # Connect to 1 and execute the reconfig command
> {code}
> zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
> null, null, -1, null, null);
> {code}
> # Verify sever 3. It was supposed to run as observer but it is running as
> participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2554) reconfig can not add new server as observer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465730#comment-15465730
]
Arshad Mohammad commented on ZOOKEEPER-2554:
As per my understanding, in
{{org.apache.zookeeper.server.quorum.QuorumPeer.updateLearnerType(QuorumVerifier)}}
bellow code causing the problem.
{code}
// I'm not in the view
if (getLearnerType()!=LearnerType.PARTICIPANT){
setLearnerType(LearnerType.PARTICIPANT);
LOG.info("Becoming a non-voting participant");
reconfigFlagSet();
return true;
}
{code}
getLearnerType() is LearnerType.OBSERVER in this case but this code changes
learner type to LearnerType.PARTICIPANT blindly.
> reconfig can not add new server as observer
> ---
>
> Key: ZOOKEEPER-2554
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.5.1, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ZOOKEEPER-2554-01.patch
>
>
> Try to add new observer server using reconfig API, server gets added as
> participant.
> STEPS:
> # create 3 node cluster.
> {code}
> server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
> server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> {code}
> # Suppose the 2 is the leader in the above cluster. Configure the new server
> as
> {code}
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
> {code}
> # Connect to 1 and execute the reconfig command
> {code}
> zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
> null, null, -1, null, null);
> {code}
> # Verify sever 3. It was supposed to run as observer but it is running as
> participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2554) reconfig can not add new server as observer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465723#comment-15465723
]
Arshad Mohammad commented on ZOOKEEPER-2554:
ZOOKEEPER-2554-01.patch is test code patch to reproduce the scenario.
> reconfig can not add new server as observer
> ---
>
> Key: ZOOKEEPER-2554
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.5.1, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ZOOKEEPER-2554-01.patch
>
>
> Try to add new observer server using reconfig API, server gets added as
> participant.
> STEPS:
> # create 3 node cluster.
> {code}
> server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
> server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> {code}
> # Suppose the 2 is the leader in the above cluster. Configure the new server
> as
> {code}
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
> {code}
> # Connect to 1 and execute the reconfig command
> {code}
> zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
> null, null, -1, null, null);
> {code}
> # Verify sever 3. It was supposed to run as observer but it is running as
> participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2554) reconfig can not add new server as observer
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2554:
---
Attachment: ZOOKEEPER-2554-01.patch
> reconfig can not add new server as observer
> ---
>
> Key: ZOOKEEPER-2554
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.5.1, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Attachments: ZOOKEEPER-2554-01.patch
>
>
> Try to add new observer server using reconfig API, server gets added as
> participant.
> STEPS:
> # create 3 node cluster.
> {code}
> server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
> server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> {code}
> # Suppose the 2 is the leader in the above cluster. Configure the new server
> as
> {code}
> server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
> server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
> {code}
> # Connect to 1 and execute the reconfig command
> {code}
> zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
> null, null, -1, null, null);
> {code}
> # Verify sever 3. It was supposed to run as observer but it is running as
> participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2554) reconfig can not add new server as observer
Arshad Mohammad created ZOOKEEPER-2554:
--
Summary: reconfig can not add new server as observer
Key: ZOOKEEPER-2554
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2554
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.5.2, 3.5.1, 3.5.0
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
Priority: Critical
Try to add new observer server using reconfig API, server gets added as
participant.
STEPS:
# create 3 node cluster.
{code}
server.0=127.0.0.1:11223:11224:participant;127.0.0.1:11222
server.1=127.0.0.1:11226:11227:participant;127.0.0.1:11225
server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
{code}
# Suppose the 2 is the leader in the above cluster. Configure the new server as
{code}
server.2=127.0.0.1:11229:11230:participant;127.0.0.1:11228
server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231
{code}
# Connect to 1 and execute the reconfig command
{code}
zkClient.reconfig("server.3=127.0.0.1:11232:11233:observer;127.0.0.1:11231",
null, null, -1, null, null);
{code}
# Verify sever 3. It was supposed to run as observer but it is running as
participant
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2513) majorChange exceptions during leader sync
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad reassigned ZOOKEEPER-2513: -- Assignee: Arshad Mohammad > majorChange exceptions during leader sync > - > > Key: ZOOKEEPER-2513 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2513 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.2 >Reporter: Alexander Shraer >Assignee: Arshad Mohammad >Priority: Critical > > In Learner.java there are exceptions being thrown in case majorChange = true, > i.e., a reconfig is encountered in the stream of updates from the leader. > There may be two problems in the way such exceptions are thrown: > 1. important actions, e.g., processTxn, will not be done if an exception is > thrown > 2. its unclear that the learner will be able to continue where it left off in > the process of syncing with the leader, if that sync is interrupted by an > exception. > This requires further investigation. Whereas similar code in Follower and > Observer is extensively tested, this code in Learner isn't tested as much. We > could build on the test case developed in ZOOKEEPER-2172 to make sure this > code works properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2513) majorChange exceptions during leader sync
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465588#comment-15465588 ] Arshad Mohammad commented on ZOOKEEPER-2513: After ZOOKEEPER-2172 fix, there is no problem with majorChange = true scenario. # yes, transaction is not processed, but this does not cause any problem. After exception, follower enters into leader election phase, then registers itself with the leader and then syncs with the leader. While syncing with leader it receives the failed transaction in the DIFF message. So reconfig was processed before the exception and transaction's PROPOSAL and COMMIT are processed after the exception. # Learner is able to continue where it left off in the process of syncing with the leader > majorChange exceptions during leader sync > - > > Key: ZOOKEEPER-2513 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2513 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.2 >Reporter: Alexander Shraer >Priority: Critical > > In Learner.java there are exceptions being thrown in case majorChange = true, > i.e., a reconfig is encountered in the stream of updates from the leader. > There may be two problems in the way such exceptions are thrown: > 1. important actions, e.g., processTxn, will not be done if an exception is > thrown > 2. its unclear that the learner will be able to continue where it left off in > the process of syncing with the leader, if that sync is interrupted by an > exception. > This requires further investigation. Whereas similar code in Follower and > Observer is extensively tested, this code in Learner isn't tested as much. We > could build on the test case developed in ZOOKEEPER-2172 to make sure this > code works properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2551) Remove Hadoop Logo from ZooKeeper documentation
Arshad Mohammad created ZOOKEEPER-2551: -- Summary: Remove Hadoop Logo from ZooKeeper documentation Key: ZOOKEEPER-2551 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2551 Project: ZooKeeper Issue Type: Bug Components: documentation Reporter: Arshad Mohammad Assignee: Arshad Mohammad Fix For: 3.5.3 ZooKeeper documentation has hadoop logo on each page's header. There is no significance to put the hadoop logo on ZooKeeper project. So hadoop logo should be removed from Zookeeper as ZooKeeper is independent of hadoop project, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2548) zooInspector does not start on Windows
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2548:
---
Component/s: contrib
> zooInspector does not start on Windows
> --
>
> Key: ZOOKEEPER-2548
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2548
> Project: ZooKeeper
> Issue Type: Bug
> Components: contrib
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2548-01.patch
>
>
> ZooInspector is very usefully tool but seems its windows scripts are not
> maintained.
> zooInspector.cmd commands fails with bellow error:
> {noformat}
> D:\workspace\ZooInspector>zooInspector.cmd
> D:\workspace\ZooInspector>#!/bin/sh
> '#!' is not recognized as an internal or external command,
> operable program or batch file.
> D:\workspace\ZooInspector># Licensed to the Apache Software Foundation (ASF)
> under one or more
> '#' is not recognized as an internal or external command,
> operable program or batch file.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2548) zooInspector does not start on Windows
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459568#comment-15459568
]
Arshad Mohammad commented on ZOOKEEPER-2548:
Submitting the fix
> zooInspector does not start on Windows
> --
>
> Key: ZOOKEEPER-2548
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2548
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2548-01.patch
>
>
> ZooInspector is very usefully tool but seems its windows scripts are not
> maintained.
> zooInspector.cmd commands fails with bellow error:
> {noformat}
> D:\workspace\ZooInspector>zooInspector.cmd
> D:\workspace\ZooInspector>#!/bin/sh
> '#!' is not recognized as an internal or external command,
> operable program or batch file.
> D:\workspace\ZooInspector># Licensed to the Apache Software Foundation (ASF)
> under one or more
> '#' is not recognized as an internal or external command,
> operable program or batch file.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2548) zooInspector does not start on Windows
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2548:
---
Attachment: ZOOKEEPER-2548-01.patch
> zooInspector does not start on Windows
> --
>
> Key: ZOOKEEPER-2548
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2548
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Attachments: ZOOKEEPER-2548-01.patch
>
>
> ZooInspector is very usefully tool but seems its windows scripts are not
> maintained.
> zooInspector.cmd commands fails with bellow error:
> {noformat}
> D:\workspace\ZooInspector>zooInspector.cmd
> D:\workspace\ZooInspector>#!/bin/sh
> '#!' is not recognized as an internal or external command,
> operable program or batch file.
> D:\workspace\ZooInspector># Licensed to the Apache Software Foundation (ASF)
> under one or more
> '#' is not recognized as an internal or external command,
> operable program or batch file.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2548) zooInspector does not start on Windows
Arshad Mohammad created ZOOKEEPER-2548:
--
Summary: zooInspector does not start on Windows
Key: ZOOKEEPER-2548
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2548
Project: ZooKeeper
Issue Type: Bug
Reporter: Arshad Mohammad
Assignee: Arshad Mohammad
ZooInspector is very usefully tool but seems its windows scripts are not
maintained.
zooInspector.cmd commands fails with bellow error:
{noformat}
D:\workspace\ZooInspector>zooInspector.cmd
D:\workspace\ZooInspector>#!/bin/sh
'#!' is not recognized as an internal or external command,
operable program or batch file.
D:\workspace\ZooInspector># Licensed to the Apache Software Foundation (ASF)
under one or more
'#' is not recognized as an internal or external command,
operable program or batch file.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459462#comment-15459462
]
Arshad Mohammad commented on ZOOKEEPER-2547:
In the submitted patch, I added client IP as the default authorized id. This
is the exactly same is being done when we use NIOServerCnxnFactory
> 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
>
> Attachments: ZOOKEEPER-2547-01.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-2547) IP ACL is not working with NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459457#comment-15459457
]
Arshad Mohammad commented on ZOOKEEPER-2547:
Test case failure is not related to this 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
>
> Attachments: ZOOKEEPER-2547-01.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] [Assigned] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad reassigned ZOOKEEPER-2355:
--
Assignee: Arshad Mohammad (was: Martin Kuchta)
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459426#comment-15459426
]
Arshad Mohammad commented on ZOOKEEPER-2517:
# I am submitting new patch ZOOKEEPER-2517-01.patch for this issue, I feel this
is very important bug and it should be fixed ASAP. Hope [~benjamin.jaton] you
wont mind it.
# Thanks [~hanm] for your suggestion, I made it testable
> 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: Critical
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2517-01.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] [Assigned] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad reassigned ZOOKEEPER-2517:
--
Assignee: Arshad Mohammad (was: Benjamin Jaton)
> 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: Critical
> Attachments: ZOOKEEPER-2517-01.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] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
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-01.patch
> 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: Critical
> Attachments: ZOOKEEPER-2517-01.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-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15459296#comment-15459296
]
Arshad Mohammad commented on ZOOKEEPER-2355:
# Submited ZOOKEEPER-2355-04.patch . This patch is for branch-3.5 and trunk,
After commit to branch-3.5 and trunk i will prepare patch for branch-3.4
# Handled comments by [~rakeshr], I got better way to inject QuorumPeer.
Modified RaceConditionTest.java also. Now I think there is no need to move the
mock classed to different class as not much code duplication
# Handled comments by [~rgs]
# Reanamed test class and test method and other small improvments
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Martin Kuchta
>Priority: Critical
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2355:
---
Fix Version/s: 3.5.3
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Martin Kuchta
>Priority: Critical
> Fix For: 3.5.3, 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2355:
---
Attachment: ZOOKEEPER-2355-04.patch
> Ephemeral node is never deleted if follower fails while reading the proposal
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
>Reporter: Arshad Mohammad
>Assignee: Martin Kuchta
>Priority: Critical
> Fix For: 3.4.10
>
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch,
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C,
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created
> is success.
> # Close the session, ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2547:
---
Description:
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
was:
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 "/n1" 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
> 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
>
> Attachments: ZOOKEEPER-2547-01.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] [Updated] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
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-01.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
> Attachments: ZOOKEEPER-2547-01.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 "/n1" 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] [Created] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
Arshad Mohammad created ZOOKEEPER-2547:
--
Summary: 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
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 "/n1" 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-2508) Many ZooKeeper tests are flaky because they proceed with zk operation without connecting to ZooKeeper server.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15435000#comment-15435000
]
Arshad Mohammad commented on ZOOKEEPER-2508:
Thanks [~phunt] for committing the patch
Thanks [~hanm], [~eribeiro] and [~rgs] for reviewing the patch.
> Many ZooKeeper tests are flaky because they proceed with zk operation without
> connecting to ZooKeeper server.
> -
>
> Key: ZOOKEEPER-2508
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2508
> Project: ZooKeeper
> Issue Type: Bug
> Components: tests
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2508-01.patch, ZOOKEEPER-2508-02.patch,
> ZOOKEEPER-2508-03.patch, ZOOKEEPER-2508-04.patch, ZOOKEEPER-2508-05.patch,
> ZOOKEEPER-2508-06.patch
>
>
> Many ZooKeeper tests are flaky because they proceed with zk operation without
> connecting to ZooKeeper server.
> Recently in our build
> {{org.apache.zookeeper.server.ZooKeeperServerMainTest.testStandalone()}}
> failed.
> After analyzing we found that it is failed because it is not waiting for
> ZooKeeper client get connected to server. In this case normally zookeeper
> client gets connected immediately but if not connected immediately the test
> case is bound to fail.
> Not only ZooKeeperServerMainTest but there are many other classes which have
> such test cases. This jira is to address all those test cases.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15434993#comment-15434993
]
Arshad Mohammad commented on ZOOKEEPER-2517:
sorry [~benjamin.jaton], I assigned the issue without asking you. Please feel
free to unassign form your or assign me if you don't have cycle to work on it.
> 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: Benjamin Jaton
>Priority: Critical
> Attachments: 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] [Assigned] (ZOOKEEPER-2416) Remove Java System property usage from ZooKeeper server code
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad reassigned ZOOKEEPER-2416:
--
Assignee: Arshad Mohammad
> Remove Java System property usage from ZooKeeper server code
>
>
> Key: ZOOKEEPER-2416
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2416
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3
>
>
> Many ZooKeeper properties are used as Java System properties in the ZooKeeper
> code.
> Some example:
> {code}
> public static int getSnapCount() {
> String sc = System.getProperty("zookeeper.snapCount");
> {code}
> {code}
> public int getGlobalOutstandingLimit() { String sc =
> System.getProperty("zookeeper.globalOutstandingLimit");
> {code}
> Using ZooKeeper properties as Java system properties causes following
> problems
> # Can not create two or more ZooKeeper Server in a single JVM
> with different properties for testing
> # The properties initialization and validation is very much mixed with actual
> business logic which should not be the case.
> ZOOKEEPER-2139 removed the ZooKeeper client side Java System properties so as
> part of this jira handling only ZooKeeper server side Java System properties
> to be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2397) Undocumented SASL properties
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15430548#comment-15430548
]
Arshad Mohammad commented on ZOOKEEPER-2397:
Above list is from the client perspective, corresponding to client which server
sasl properties are not documented, otherwise there are many other SASL
properties which are not documented.
For example, bellow properties are not documented
{code}
SASLAuthenticationProvider.superPassword
kerberos.removeHostFromPrincipal
kerberos.removeRealmFromPrincipal
{code}
ZOOKEEPER-2416 will segregate the all ZooKeeper properties,
After this jira, we can easily find and document all the undocumented ZooKeeper
properties
> Undocumented SASL properties
>
>
> Key: ZOOKEEPER-2397
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2397
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: documentation
>Affects Versions: 3.4.8, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.5.3, 3.6.0, 3.4.10
>
> Attachments: ZOOKEEPER-2397.patch
>
>
> There are a number of properties spread across the code that do not appear in
> the docs. For example, zookeeper.allowSaslFailedClients isn't documented
> afaict.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2416) Remove Java System property usage from ZooKeeper server code
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2416:
---
Comment: was deleted
(was: [~pogonumber12] why are u adding these junk comments here ?)
> Remove Java System property usage from ZooKeeper server code
>
>
> Key: ZOOKEEPER-2416
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2416
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: Arshad Mohammad
> Fix For: 3.5.3
>
>
> Many ZooKeeper properties are used as Java System properties in the ZooKeeper
> code.
> Some example:
> {code}
> public static int getSnapCount() {
> String sc = System.getProperty("zookeeper.snapCount");
> {code}
> {code}
> public int getGlobalOutstandingLimit() { String sc =
> System.getProperty("zookeeper.globalOutstandingLimit");
> {code}
> Using ZooKeeper properties as Java system properties causes following
> problems
> # Can not create two or more ZooKeeper Server in a single JVM
> with different properties for testing
> # The properties initialization and validation is very much mixed with actual
> business logic which should not be the case.
> ZOOKEEPER-2139 removed the ZooKeeper client side Java System properties so as
> part of this jira handling only ZooKeeper server side Java System properties
> to be removed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2517:
---
Assignee: Benjamin Jaton
> 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: Benjamin Jaton
>Priority: Critical
> Attachments: 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-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15427669#comment-15427669
]
Arshad Mohammad commented on ZOOKEEPER-2517:
Thanks [~benjamin.jaton] for reporting and submitting a patch.
One review comment on the patch.
Can we handled NumberFormatException and use default in case of
NumberFormatException.
> 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
>Priority: Critical
> Attachments: 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-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15422360#comment-15422360
]
Arshad Mohammad commented on ZOOKEEPER-1467:
Hi [~gbraccialli],
server principal can have three parts {{serviceName/hostName@realm}}
serviceName can be configured with {{zookeeper.sasl.client.username}}
realm can be configured with {{zookeeper.server.realm}}
only hostName is not configurable. It is taken same as the server IP.
zookeeper.server.principal is being introduced to give the complete principal
like {{-Dzookeeper.server.principal=zookeeper/hadoop.hadoop@hadoop.com}}
where hadoop.hadoop.com is the hostName
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Critical
> Labels: Security, client, kerberos, sasl
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-1260:
---
Attachment: ZOOKEEPER-1260-01.patch
Submitting the implementation of ZooKeeper audit log feature. Please refer
attached {{zookeeperAuditLogs.pdf}} for implementation details.
> Audit logging in ZooKeeper servers.
> ---
>
> Key: ZOOKEEPER-1260
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
> Project: ZooKeeper
> Issue Type: New Feature
>Affects Versions: 3.4.0
>Reporter: Mahadev konar
>Assignee: Arshad Mohammad
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1260-01.patch, zookeeperAuditLogs.pdf
>
>
> Lots of users have had questions on debugging which client changed what znode
> and what updates went through a znode. We should add audit logging as in
> Hadoop (look at Namenode Audit logging) to log which client changed what in
> the zookeeper servers. This could just be a log4j audit logger.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-1260: --- Attachment: zookeeperAuditLogs.pdf > Audit logging in ZooKeeper servers. > --- > > Key: ZOOKEEPER-1260 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260 > Project: ZooKeeper > Issue Type: New Feature >Affects Versions: 3.4.0 >Reporter: Mahadev konar >Assignee: Arshad Mohammad > Fix For: 3.6.0 > > Attachments: zookeeperAuditLogs.pdf > > > Lots of users have had questions on debugging which client changed what znode > and what updates went through a znode. We should add audit logging as in > Hadoop (look at Namenode Audit logging) to log which client changed what in > the zookeeper servers. This could just be a log4j audit logger. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2172) Cluster crashes when reconfig a new node as a participant
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arshad Mohammad updated ZOOKEEPER-2172:
---
Attachment: ZOOKEEPER-2172-07.patch
Thanks [~shralex] for authoring the patch, patch is improved a lot.
It is good that the changes you introduced in ZOOKEEPER-2172-05.patch have
removed in the latest patch and created new jira to address those concerns.
I corrected following nits in the ZOOKEEPER-2172-06.patch and submitted new
patch
{noformat}
ZOOKEEPER-2172-06.patch:10: trailing whitespace.
ZOOKEEPER-2172-06.patch:30: trailing whitespace.
boolean majorChange =
ZOOKEEPER-2172-06.patch:31: space before tab in indent.
self.processReconfig(qv,
ByteBuffer.wrap(qp.getData()).getLong(), qp.getZxid(), true);
ZOOKEEPER-2172-06.patch:35: trailing whitespace.
}
ZOOKEEPER-2172-06.patch:111: trailing whitespace.
*
{noformat}
> Cluster crashes when reconfig a new node as a participant
> -
>
> Key: ZOOKEEPER-2172
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2172
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, quorum, server
>Affects Versions: 3.5.0
> Environment: Ubuntu 12.04 + java 7
>Reporter: Ziyou Wang
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2172-02.patch, ZOOKEEPER-2172-03.patch,
> ZOOKEEPER-2172-04.patch, ZOOKEEPER-2172-06.patch, ZOOKEEPER-2172-07.patch,
> ZOOKEEPER-2172.patch, ZOOKEPER-2172-05.patch, history.txt, node-1.log,
> node-2.log, node-3.log, zoo-1.log, zoo-2-1.log, zoo-2-2.log, zoo-2-3.log,
> zoo-2.log, zoo-2212-1.log, zoo-2212-2.log, zoo-2212-3.log, zoo-3-1.log,
> zoo-3-2.log, zoo-3-3.log, zoo-3.log, zoo-4-1.log, zoo-4-2.log, zoo-4-3.log,
> zoo.cfg.dynamic.1005d, zoo.cfg.dynamic.next, zookeeper-1.log,
> zookeeper-1.out, zookeeper-2.log, zookeeper-2.out, zookeeper-3.log,
> zookeeper-3.out
>
>
> The operations are quite simple: start three zk servers one by one, then
> reconfig the cluster to add the new one as a participant. When I add the
> third one, the zk cluster may enter a weird state and cannot recover.
>
> I found “2015-04-20 12:53:48,236 [myid:1] - INFO [ProcessThread(sid:1
> cport:-1)::PrepRequestProcessor@547] - Incremental reconfig” in node-1 log.
> So the first node received the reconfig cmd at 12:53:48. Latter, it logged
> “2015-04-20 12:53:52,230 [myid:1] - ERROR
> [LearnerHandler-/10.0.0.2:55890:LearnerHandler@580] - Unexpected exception
> causing shutdown while sock still open” and “2015-04-20 12:53:52,231 [myid:1]
> - WARN [LearnerHandler-/10.0.0.2:55890:LearnerHandler@595] - *** GOODBYE
> /10.0.0.2:55890 ”. From then on, the first node and second node
> rejected all client connections and the third node didn’t join the cluster as
> a participant. The whole cluster was done.
>
> When the problem happened, all three nodes just used the same dynamic
> config file zoo.cfg.dynamic.1005d which only contained the first two
> nodes. But there was another unused dynamic config file in node-1 directory
> zoo.cfg.dynamic.next which already contained three nodes.
>
> When I extended the waiting time between starting the third node and
> reconfiguring the cluster, the problem didn’t show again. So it should be a
> race condition problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2238) Support limiting the maximum number of connections/clients to a zookeeper server.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arshad Mohammad updated ZOOKEEPER-2238: --- Attachment: ZOOKEEPER-2238-07.patch > Support limiting the maximum number of connections/clients to a zookeeper > server. > - > > Key: ZOOKEEPER-2238 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2238 > Project: ZooKeeper > Issue Type: Improvement >Reporter: nijel >Assignee: Arshad Mohammad > Attachments: ZOOKEEPER-2238-05.patch, ZOOKEEPER-2238-06.patch, > ZOOKEEPER-2238-07.patch, ZOOKEEPER-2238.2.patch, ZOOKEEPER-2238.3.patch, > ZOOKEEPER-2238.4.patch, ZOOKEEPER-2238.diff > > > Currently zookeeper have the feature of limiting the maximum number of > connection/client per IP or Host (maxClientCnxns). > But to safe guard zookeeper server from DoS attack due to many clients from > different IPs, it is better to have a limit of total number of > connections/clients to a a single member of the ZooKeeper ensemble as well. > So the idea is to introduce a new configuration to limit the maximum number > of total connections/clients. > Please share your thoughts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
