[jira] [Commented] (ZOOKEEPER-1990) suspicious instantiation of java Random instances

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-1990:
---

Hi [~nkalmar], I raised the possibility of using _ThreadLocalRandom_, so my two 
cents: we can call _Random()_ (option 1), imo. _ThreadLocalRandom_ advantage is 
avoiding thread contention and overhead of sharing a global math.Random among 
many threads, but I don't think this is a issue with current ZK codebase.

> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Norbert Kalmar
>Priority: Critical
> Fix For: 3.6.0, 3.5.5
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why 
> aren't we just calling "new Random()" in these cases? (even for the tests I 
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75:   sourceOfRandomness = new Random(System.currentTimeMillis() ^ 
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ZOOKEEPER-3105) Character coding problem occur when create a node using python3

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-3105:
---

Could you please post a code snippet that reproduces this error?

Best,

Edward

> Character coding problem occur when create a node using python3
> ---
>
> Key: ZOOKEEPER-3105
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3105
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: contrib
>Affects Versions: 3.5.0
> Environment: linux
>Reporter: yang hao
>Priority: Major
> Fix For: 3.5.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> when creating a node using python3,  InvalidACLException occurs all the time. 
> it`s caused by imcompatible way of parsing acl passed through python3 api.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ZOOKEEPER-3035) what does these opeartion code mean

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro resolved ZOOKEEPER-3035.
---
Resolution: Not A Problem

> what does these opeartion code mean
> ---
>
> Key: ZOOKEEPER-3035
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3035
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: liyuzhou
>Priority: Minor
>
> I'm reading the source code, but I often can not understand the operation 
> code mean in OpCode.java. For example , the sync operation code is 9, but I 
> can't understand what does this mean, and the source code has nothing about 
> the code description. Do we have some wiki or document abount operation code?
> {code:java}
> public interface OpCode {
> public final int notification = 0;
> public final int setACL = 7;
> public final int getChildren = 8;
> public final int sync = 9;
> public final int ping = 11;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ZOOKEEPER-3035) what does these opeartion code mean

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-3035:
---

Please, don't open Jira issues to ask questions. Use ZK mailing lists (user 
and/or dev) to ask such things.

 

The OpCode is the number that identifies a given operation (getData, setData, 
exists, etc) on the wire protocol. When the message is serialized/deserialize 
the value tells what kind of message it is.

> what does these opeartion code mean
> ---
>
> Key: ZOOKEEPER-3035
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3035
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: liyuzhou
>Priority: Minor
>
> I'm reading the source code, but I often can not understand the operation 
> code mean in OpCode.java. For example , the sync operation code is 9, but I 
> can't understand what does this mean, and the source code has nothing about 
> the code description. Do we have some wiki or document abount operation code?
> {code:java}
> public interface OpCode {
> public final int notification = 0;
> public final int setACL = 7;
> public final int getChildren = 8;
> public final int sync = 9;
> public final int ping = 11;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ZOOKEEPER-3006) Potential NPE in ZKDatabase#calculateTxnLogSizeLimit

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro reassigned ZOOKEEPER-3006:
-

Assignee: Edward Ribeiro

> Potential NPE in ZKDatabase#calculateTxnLogSizeLimit
> 
>
> Key: ZOOKEEPER-3006
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3006
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: lujie
>Assignee: Edward Ribeiro
>Priority: Major
>
> I have found a potential NPE in ZKDatabase#calculateTxnLogSizeLimit:
>  
> {code:java}
> //ZKDatabase
> public long calculateTxnLogSizeLimit() {
> long snapSize = 0;
> try {
> snapSize = snapLog.findMostRecentSnapshot().length();
> } catch (IOException e) {
> LOG.error("Unable to get size of most recent snapshot");
> }
> return (long) (snapSize * snapshotSizeFactor);
> }
> {code}
>  in FileTxnSnapLog#findMostRecentSnapshot(), it will return the result of  
> FileSnap#findMostRecentSnapshot:
> {code:java}
> // called by FileTxnSnapLog#findMostRecentSnapshot()
> public File findMostRecentSnapshot() throws IOException {
> List files = findNValidSnapshots(1);
> if (files.size() == 0) {
> return null;
> }
> return files.get(0);
> }
> {code}
> So it will return null when the files sizes is 0, but 
> ZKDatabase#calculateTxnLogSizeLimit has no null checker
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ZOOKEEPER-1990) suspicious instantiation of java Random instances

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-1990:
---

As you are tackling this issue, it would be nice to evaluate the use of 
ThreadLocalRandom ( 
[https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadLocalRandom.html]
 ) instead of Random, if possible. It's been available since JDK7 and offers 
less contention and overhead.

> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Critical
> Fix For: 3.5.4, 3.6.0
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why 
> aren't we just calling "new Random()" in these cases? (even for the tests I 
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75:   sourceOfRandomness = new Random(System.currentTimeMillis() ^ 
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (ZOOKEEPER-2921) fsyncWarningThresholdMS is applied on each getChannel().force() - also needed on entire commit

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2921 at 10/21/17 3:34 PM:
-

Hi [~randgalt] and [~phunt] 

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!



was (Author: eribeiro):
Hi [~randgalt] and [~phunt] :smile:

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!


> fsyncWarningThresholdMS is applied on each getChannel().force() - also needed 
> on entire commit
> --
>
> Key: ZOOKEEPER-2921
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2921
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.3
>Reporter: Jordan Zimmerman
>Priority: Minor
>
> FileTxnLog.commit() has a warning when an individual sync takes longer than 
> {{fsyncWarningThresholdMS}}. However, it would also be useful to warn when 
> the entire commit operation takes longer than {{fsyncWarningThresholdMS}} as 
> this can cause client connection failures. Currently, commit() can take 
> longer than 2/3 of a session but still not log a warning.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2921) fsyncWarningThresholdMS is applied on each getChannel().force() - also needed on entire commit

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2921:
---

Hi [~randgalt] and [~phunt] :smile:

{quote}
That said having such a warning when request latency exceeds some threshold 
would also be useful.
{quote}

Isn't that what ZOOKEEPER-2770 is all about? Or I misunderstood this issue? 
There's a corresponding stale patch already: 
https://github.com/apache/zookeeper/pull/307

Wdyt? Please, let me know.

Cheers!


> fsyncWarningThresholdMS is applied on each getChannel().force() - also needed 
> on entire commit
> --
>
> Key: ZOOKEEPER-2921
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2921
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.5.3
>Reporter: Jordan Zimmerman
>Priority: Minor
>
> FileTxnLog.commit() has a warning when an individual sync takes longer than 
> {{fsyncWarningThresholdMS}}. However, it would also be useful to warn when 
> the entire commit operation takes longer than {{fsyncWarningThresholdMS}} as 
> this can cause client connection failures. Currently, commit() can take 
> longer than 2/3 of a session but still not log a warning.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2814) Ignore space after comma in connection string

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2814:
---

Hi [~nikbhi15],

FYI, the trim of the host string seems to be fixed on branch-3.5 and master, 
doesn't it? See 
https://github.com/apache/zookeeper/blob/branch-3.5/src/java/main/org/apache/zookeeper/common/StringUtils.java#L37
 

While it is not fixed on branch-3.4 yet: 
https://github.com/apache/zookeeper/blob/branch-3.4/src/java/main/org/apache/zookeeper/client/ConnectStringParser.java#L65

I suggest that you add a method to check the host string with spaces after (and 
before) the comma.

> Ignore space after comma in connection string
> -
>
> Key: ZOOKEEPER-2814
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2814
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Viliam Durina
>Assignee: Nikhil Ashok Bhide
>Priority: Minor
>
> I'm using the following connection string:
> {{10.0.0.179:2181,10.0.0.176:2181}}
> However, I get:
> {{java.net.UnknownHostException: 10.0.0.176: Name or service not known
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at ...
> ...}}
> The problem was the space after the comma. I suggest to either make the space 
> optional or produce error on it, as this is a real pain to spot. Using the 
> space also makes the connect string more readable. Spaces are not allowed in 
> domain names.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2614) Port ZOOKEEPER-1576 to branch3.4

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2614:
---

Hi Thomas, take a look at 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute on how to 
contribute via Github. I can take a look today yet or as soon as it is 
available.

> Port ZOOKEEPER-1576 to branch3.4
> 
>
> Key: ZOOKEEPER-2614
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2614
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.4.11
>
> Attachments: ZOOKEEPER-2614.branch-3.4.00.patch
>
>
> ZOOKEEPER-1576 handles UnknownHostException and it good to have this change 
> for 3.4 branch as well. Porting the changes to 3.4 after resolving the 
> conflicts



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2591:
---

Cool, got it. It is the only edge case previously described and your solution 
is nice. Excuse me for disturbing the talk with a spurious example.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:11 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

*So, even though the creation follows the same path, the container deletion has 
a different one.*

But I totally agree with you that this issue can not be worth working on, or 
could use something different from adding a checkACL. :)




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

**So, even though the creation follows the same path, the container deletion 
has a different one.**



> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:08 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392

**So, even though the creation follows the same path, the container deletion 
has a different one.**




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392



> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2591 at 7/3/17 3:06 PM:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed. My misunderstanding was because this line:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L402

was not present in this block:

https://github.com/apache/zookeeper/blob/a0eba7abd002498631da8d8127261c297c911590/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java#L375-L392




was (Author: eribeiro):
[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2591:
---

[~randgalt], oops, excuse me! I didn't look at this issue nor this part of the 
code since the issue was closed.

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2591:
---

[~randgalt], another edge case would be the following: a client create a 
container znode and populate it with children znodes. This client is the only 
in charge of deleting the children. Another clients should only be able to read 
the children znode contents, but a misbehaved client can delete children znodes 
in the container znode. With ACL properly set this other clients would not be 
able to delete the children of the master client. Does it make sense?

> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>
> Container nodes check the ACL before creation, but the deletion doesn't check 
>  the ACL rights. The code below succeeds even tough we removed ACL access 
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Sure [~hanm], gonna port it to branch-3.5! :)

By the way, I saw that {{FileTxnSnapLogTest}}, that this patch uses, doesn't 
exist on branch-3.5. It was created as part of ZOOKEEPER-261 that both of us 
reviewed, but it got only committed on master. It was that on purpose [~breed]?

Best regards!

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Hey [~ckulkarni], I didn't have any spare cycle to spend on ZK issues, but got 
to resume it now. Thanks for bringing this up. Yup, I think this unit test is 
enough, so thank you **very much** for the test case. :)

[~hanm], would you mind to take a look at this PR, please?

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2662:
--
Fix Version/s: 3.6.0

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Edward Ribeiro
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2739 at 3/25/17 4:34 AM:


Hi [~vincentpoon], I have created a new PR for ZOOKEEPER-2280 and rebased it to 
current master. It also applies to branch-3.5, btw. The jira issue has the 
updated link now.

There are two review comments by [~fpj] yet to be addressed (I commented on new 
PR) and further review/tests. Gonna do that next, so that we can get this patch 
in asap. Any comment on PR is welcome in the meantime. :)


was (Author: eribeiro):
Hi [~vincentpoon], I have created a new PR and rebased it to current master. It 
also applies to branch-3.5. There are two review comments by [~fpj] yet to be 
addressed (I commented on new PR) and further review/tests. Gonna do that next. 
Any comment on PR is welcome in the meantime. :)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2739:
---

Hi [~vincentpoon], I have created a new PR and rebased it to current master. It 
also applies to branch-3.5. There are two review comments by [~fpj] yet to be 
addressed (I commented on new PR) and further review/tests. Gonna do that next. 
Any comment on PR is welcome in the meantime. :)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2659 at 3/25/17 2:49 AM:


Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen this jira issue and the PR you made, so that others in the 
community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!



was (Author: eribeiro):
Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen the PR you made, so that others in the community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Assignee: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Hey [~praste],

I am no committer, but I see that you have invested *a lot* of work on this. 
This has been the subject of a previous and unfinished JIRA issue, 
ZOOKEEPER-2342, so definitely there is an interest on this matter. Wouldn't you 
like to reopen the PR you made, so that others in the community can take a look?

I will take the liberty to ping some ZK committers -- [~arshadmohammad], 
[~hanm] so that they can take a look when/if they have a spare cycles. I hope 
you don't mind guys! I know you are pretty busy, but migrating to newer 
versions of log4j is a must have for future ZK versions, imo.

Cheers!


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Assignee: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2739) maxClientCnxns not working in NettyServerCnxnFactory

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2739:
---

Hi [~vincentpoon],

I started working on this exact same issue long before, but got side tracked by 
other commitments. Let's chat! ;)

> maxClientCnxns not working in NettyServerCnxnFactory
> 
>
> Key: ZOOKEEPER-2739
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2739
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.0, 3.6.0
>Reporter: Vincent Poon
> Attachments: MaxNettyCnxnsTest.patch
>
>
> The maxClientCnxns field isn't being used in NettyServerCnxnFactory, and 
> therefore the connection limit isn't observed.
> See attached test



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2736) Add a connection rate limiter

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2736 at 3/23/17 7:56 PM:


Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

PS: I was unable to apply your patch to branch-3.4 and branch-3.5. :( Did you 
generate your patch with a {{git diff --no-prefix}} or equivalent? 


was (Author: eribeiro):
Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

> Add a connection rate limiter
> -
>
> Key: ZOOKEEPER-2736
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2736
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Vincent Poon
> Attachments: ZOOKEEPER-2736.v1.patch
>
>
> Currently the maxClientCnxns property only limits the aggregate number of 
> connections from a client, but not the rate at which connections can be 
> created.
> This patch adds a configurable connection rate limiter which limits the rate 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2736) Add a connection rate limiter

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2736:
---

Hey, [~vincentpoon], nice initiative!

I remember some past discussion about introducing a rate limiter into ZK 
codebase, particularly in the context of ZOOKEEPER-2693, so you may have to 
take a look there first to see what the others contributors have in mind. Also, 
*and most important*, we are not using patch upload + review board to accept 
patches in ZooKeeper anymore. Please, open a PR on Github as specified here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards

> Add a connection rate limiter
> -
>
> Key: ZOOKEEPER-2736
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2736
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Vincent Poon
> Attachments: ZOOKEEPER-2736.v1.patch
>
>
> Currently the maxClientCnxns property only limits the aggregate number of 
> connections from a client, but not the rate at which connections can be 
> created.
> This patch adds a configurable connection rate limiter which limits the rate 
> as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2705) Container node remains indefinitely after session has long expired!

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2705:
---

I am afraid there's no timeline yet. But you can follow and engange on the 
undergoing discussion about 3.5.x release at zookeeper-user mailing list thread 
below.

http://zookeeper-user.578899.n2.nabble.com/Query-3-5-x-version-as-alpha-td7582952.html

Cheers!

> Container node remains indefinitely after session has long expired!
> ---
>
> Key: ZOOKEEPER-2705
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2705
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.1
> Environment: 5 x RHEL 2.6.32-431.29.2.el6.x86_64
>Reporter: Steve Fitzgerald
>
> Zookeeper version: 3.5.1-alpha
> Curator Framework version: 3.2.0
> We have a 5 node cluster. When we register a service instance everything is 
> created within zookeeper successfully, e.g. for a service names 
> "fake-test-service" I can see the following created:
> 1. /api/enablement/fake-test-service
> 2. /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5
> When I abnormally kill (kill -9) the process that the service is registered 
> from I expect both of the above to get removed by zookeeper when it expires 
> the session. But only 
> /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5 gets 
> removed successfully.
> Here is a snippet of the log file:
> {noformat}
> 2017-02-23 05:50:00,977 [myid:5] - TRACE 
> [SessionTracker:SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:ZooKeeperServer@384][] - Expiring session 0x502dbce4df6, 
> timeout of 4ms exceeded
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:QuorumZooKeeperServer@132][] - Submitting global closeSession 
> request for session 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::ZooTrace@90][] - :Psessionid:0x502dbce4df6 type:closeSession 
> cxid:0x0 zxid:0xfffe txntype:unknown reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - INFO  [ProcessThread(sid:5 
> cport:-1)::PrepRequestProcessor@649][] - Processed session termination for 
> sessionid: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::CommitProcessor@340][] - Processing request:: 
> sessionid:0x502dbce4df6 type:closeSession cxid:0x0 zxid:0x1d0003 
> txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::Leader@1066][] - Proposing:: sessionid:0x502dbce4df6 
> type:closeSession cxid:0x0 zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@787][] - Ack 
> zxid: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@790][] - 
> outstanding proposal: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@793][] - 
> outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.161:55588:CommitProcessor@327][] - Committing 
> request:: sessionid:0x502dbce4df6 type:closeSession cxid:0x0 
> zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,983 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.162:47580:Leader@808][] - outstanding is 0
> 2017-02-23 05:50:00,983 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.160:41119:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,983 [myid:5] - TRACE 
> 

[jira] [Commented] (ZOOKEEPER-2705) Container node remains indefinitely after session has long expired!

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2705:
---

Hi [~stondofitz], 

Looks like you hit https://issues.apache.org/jira/browse/ZOOKEEPER-2464 that 
was recently fixed by https://issues.apache.org/jira/browse/ZOOKEEPER-2680 

TL;DR: {{DataNode.getChildren()}} could either return an empty collection or 
null, and this broke ContainerManager at line 151, as shown in your log.

Could you confirm it is the same issue, please?

> Container node remains indefinitely after session has long expired!
> ---
>
> Key: ZOOKEEPER-2705
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2705
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.5.1
> Environment: 5 x RHEL 2.6.32-431.29.2.el6.x86_64
>Reporter: Steve Fitzgerald
>
> Zookeeper version: 3.5.1-alpha
> Curator Framework version: 3.2.0
> We have a 5 node cluster. When we register a service instance everything is 
> created within zookeeper successfully, e.g. for a service names 
> "fake-test-service" I can see the following created:
> 1. /api/enablement/fake-test-service
> 2. /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5
> When I abnormally kill (kill -9) the process that the service is registered 
> from I expect both of the above to get removed by zookeeper when it expires 
> the session. But only 
> /api/enablement/fake-test-service/bb831396-5c55-4456-a7c0-5950ba294fd5 gets 
> removed successfully.
> Here is a snippet of the log file:
> {noformat}
> 2017-02-23 05:50:00,977 [myid:5] - TRACE 
> [SessionTracker:SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:ZooKeeperServer@384][] - Expiring session 0x502dbce4df6, 
> timeout of 4ms exceeded
> 2017-02-23 05:50:00,977 [myid:5] - INFO  
> [SessionTracker:QuorumZooKeeperServer@132][] - Submitting global closeSession 
> request for session 0x502dbce4df6
> 2017-02-23 05:50:00,977 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::ZooTrace@90][] - :Psessionid:0x502dbce4df6 type:closeSession 
> cxid:0x0 zxid:0xfffe txntype:unknown reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - TRACE [ProcessThread(sid:5 
> cport:-1)::SessionTrackerImpl@208][] - Session closing: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - INFO  [ProcessThread(sid:5 
> cport:-1)::PrepRequestProcessor@649][] - Processed session termination for 
> sessionid: 0x502dbce4df6
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::CommitProcessor@340][] - Processing request:: 
> sessionid:0x502dbce4df6 type:closeSession cxid:0x0 zxid:0x1d0003 
> txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,978 [myid:5] - DEBUG [ProcessThread(sid:5 
> cport:-1)::Leader@1066][] - Proposing:: sessionid:0x502dbce4df6 
> type:closeSession cxid:0x0 zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@787][] - Ack 
> zxid: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@790][] - 
> outstanding proposal: 0x1d0003
> 2017-02-23 05:50:00,981 [myid:5] - TRACE [SyncThread:5:Leader@793][] - 
> outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.164:38716:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@790][] - outstanding proposal: 
> 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.161:55588:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,982 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.161:55588:CommitProcessor@327][] - Committing 
> request:: sessionid:0x502dbce4df6 type:closeSession cxid:0x0 
> zxid:0x1d0003 txntype:-11 reqpath:n/a
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@787][] - Ack zxid: 0x1d0003
> 2017-02-23 05:50:00,982 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.162:47580:Leader@793][] - outstanding proposals all
> 2017-02-23 05:50:00,983 [myid:5] - DEBUG 
> [LearnerHandler-/10.24.128.162:47580:Leader@808][] - outstanding is 0
> 2017-02-23 05:50:00,983 [myid:5] - TRACE 
> [LearnerHandler-/10.24.128.160:41119:Leader@787][] - 

[jira] [Commented] (ZOOKEEPER-2700) Force ZooKeeper to generate snapshot

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2700:
---

Hi [~flier],

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

Additional comments I will post on the GH review comment.

Cheers!

> Force ZooKeeper to generate snapshot
> 
>
> Key: ZOOKEEPER-2700
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2700
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Flier Lu
>Priority: Minor
>
> When cold backup or remote offline sync Zookeeper instances, we need the 
> latest snapshot.
> Add a four letter `snap` command to force Zookeeper to generate snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2700) Force ZooKeeper to generate snapshot

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2700 at 2/17/17 3:07 PM:


Hi [~flier],

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

3) Where are your unit tests? :) 

Additional comments I will post on the GH review comment.

Cheers!


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

Some observations: 

1) this issue is a duplicate of ZOOKEEPER-1729 so I am marking it as such.

2) based on discussions on ZOOKEEPER-1729 (please, read it) and the security 
problems related on ZOOKEEPER-2693, implementing this command as a 4lw is a big 
*NO*. I think it could be be implemented as a JMX command and/or a ServerAdmin 
command tough.

Additional comments I will post on the GH review comment.

Cheers!

> Force ZooKeeper to generate snapshot
> 
>
> Key: ZOOKEEPER-2700
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2700
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Flier Lu
>Priority: Minor
>
> When cold backup or remote offline sync Zookeeper instances, we need the 
> latest snapshot.
> Add a four letter `snap` command to force Zookeeper to generate snapshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ZOOKEEPER-2688) rmr leads to "Node does not exist"

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2688 at 2/9/17 2:03 PM:
---

Hi [~ror6ax], 

The {{rmr}} calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) then it traverses the list, calling ZK delete method for each absolute 
path.

Based on the znode path you posted only, I *guess* that is happening a *race 
condition* as below:

0. Suppose that {{/vault}} has a lot of children znodes, many levels deep (this 
is not really necessary if the actions interleaving is just precise).

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so I think it's been used 
for distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?


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

The rmr calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) it traverses the list and calling ZK delete method for each path.

Based on the znode path you posted only, I *guess* that is happening a race 
condition as below:

0. Suppose that {{/vault}} is has a lot of children znodes, many levels deep.

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so it's been used for 
distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?

> rmr leads to "Node does not exist"
> --
>
> Key: ZOOKEEPER-2688
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2688
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Gregory Reshetniak
>
> Issuing rmr /vault leads to Node does not exist: 
> /vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28
> I know that rmr is getting deprecated in next version, but I think this might 
> be cluster consistency bug.
> Please advice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2688) rmr leads to "Node does not exist"

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2688:
---

Hi [~ror6ax], 

The rmr calls a utility method to recursively delete a root znode and its 
children. This method operates in two steps: a) first it traverses the tree 
from the root path and stores the absolute paths for root and children in a 
list. b) it traverses the list and calling ZK delete method for each path.

Based on the znode path you posted only, I *guess* that is happening a race 
condition as below:

0. Suppose that {{/vault}} is has a lot of children znodes, many levels deep.

1. Also, *suppose*  
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} is an 
ephemeral node (it has the word "lock" in its path, so it's been used for 
distributed locking). The session that owns this ephemeral node has been 
closed, then znode will be removed;

2. The tree traversal method I cited above gets 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} and 
adds the path to the list *just before* it has been removed (miliseconds 
before).

3. ZK deletes 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}};

4. the list of paths to be delete is traversed (remember: a long list) and 
*eventually* reaches 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} but 
when it try to delete it there is an exception because it has already been 
deleted by ZK itself;

Does it make sense?

Please, it's just my theory for what is happening.

PS: Even though {{rmr}} is being deprecated in favor of {{deleteAll}}, it also 
uses the same utility class so this behavior could potentially happen with with 
{{deleteAll}}.

*OTOH*, it can indeed be some sort of inconsistency. Did you try to issue a ls 
or get command on 
{{/vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28}} 
*after the error* to see if it really exists? Or try to remove it via delete?

> rmr leads to "Node does not exist"
> --
>
> Key: ZOOKEEPER-2688
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2688
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Gregory Reshetniak
>
> Issuing rmr /vault leads to Node does not exist: 
> /vault/core/_lock/_c_e393e8a4d2c984178373be528a25404a-lock-28
> I know that rmr is getting deprecated in next version, but I think this might 
> be cluster consistency bug.
> Please advice.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2665) Port QA github pull request build to branch 3.4 and 3.5

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2665:
---

I am not a committer myself, but pinging [~hanm] & [~fpj] ;) 

> Port QA github pull request build to branch 3.4 and 3.5
> ---
>
> Key: ZOOKEEPER-2665
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2665
> Project: ZooKeeper
>  Issue Type: Test
>  Components: build
>Reporter: Flavio Junqueira
> Fix For: 3.5.3, 3.4.11
>
>
> We have QA build for pull requests against master but not against branches 
> 3.4 and 3.5. We need to port the necessary wiring to do it, it shouldn't be 
> difficult.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2672) Remove CHANGE.txt

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2672:
---

[~rakeshr], Yup, I have been following the discussions and totally agree with 
you. :) No more questions by me. 

> Remove CHANGE.txt
> -
>
> Key: ZOOKEEPER-2672
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2672
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
>Assignee: Michael Han
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> The CHANGE.txt is already not the source of truth of what's changed after we 
> migrating to git - most of the git commits in recent couple of months don't 
> update CHANGE.txt. The option of updating CHANGE.txt during commit flow 
> automatically is none trivial, and do that manually is cumbersome and error 
> prone.
> The consensus is we would rely on source control revision logs instead of 
> CHANGE.txt moving forward; see 
> https://www.mail-archive.com/dev@zookeeper.apache.org/msg37108.html for more 
> details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2662) Export a metric for txn log sync times

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2662:
---

Ops, sorry for delaying this issue, gonna resume asap. Any feedback is welcome. 
:) 

Thanks!

> Export a metric for txn log sync times
> --
>
> Key: ZOOKEEPER-2662
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2662
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Edward Ribeiro
> Attachments: ZOOKEEPER-2662.diff
>
>
> In FileTxnLog there is code that records the amount of time required to fsync 
> the txn log in order to warn if that time exceeds a configurable threshold. 
> This information should also be exported as a metric available by JMX so an 
> important aspect of quorum performance can be monitored. 
> ZooKeeperServerMXBean carries some global latency information for the server 
> process already, seems like a good place to put it if not an entirely new 
> bean for the TxnLog. After ZOOKEEPER-2310 might want to collect the same 
> information for snapshots. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2665) Port QA github pull request build to branch 3.4 and 3.5

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2665:
---

Hey [~eolivelli], thanks for stepping up. You can assign the issue to yourself, 
btw. I will provide the best support I can do. :)

Cheers,
Eddie

> Port QA github pull request build to branch 3.4 and 3.5
> ---
>
> Key: ZOOKEEPER-2665
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2665
> Project: ZooKeeper
>  Issue Type: Test
>  Components: build
>Reporter: Flavio Junqueira
> Fix For: 3.5.3, 3.4.11
>
>
> We have QA build for pull requests against master but not against branches 
> 3.4 and 3.5. We need to port the necessary wiring to do it, it shouldn't be 
> difficult.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2680) Correct DataNode.getChildren() inconsistent behaviour.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2680:
---

The "Unsupported major.minor version 51.0" usually happens 'cause the code was 
compiled with a higher version JDK and run on a lower version JRE. In this 
particular case, looks like {{org/apache/kerby/kerberos/kerb}} was compiled on 
JDK7 and run on JRE6. Further info:

http://stackoverflow.com/questions/10382929/how-to-fix-java-lang-unsupportedclassversionerror-unsupported-major-minor-versi

http://stackoverflow.com/questions/20690143/java-unsupported-major-minor-version-51-0





> Correct DataNode.getChildren() inconsistent behaviour.
> --
>
> Key: ZOOKEEPER-2680
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2680
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.9, 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2680-01.patch
>
>
> DataNode.getChildren() API returns null and empty set if there are no 
> children in it depending on when the API is called. DataNode.getChildren() 
> API behavior should be changed and it should always return empty set if the 
> node does not have any child
> *DataNode.getChildren() API Current Behavior:*
> # returns null initially
> When DataNode is created and no children are added yet, 
> DataNode.getChildren() returns null
> # returns empty set after all the children are deleted:
> created a Node
> add a child
> delete the child
> DataNode.getChildren() returns empty set.
> After fix DataNode.getChildren() should return empty set in all the above 
> cases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (ZOOKEEPER-2673) projet

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro resolved ZOOKEEPER-2673.
---
Resolution: Invalid

As this issue has been open a week ago without any description or a relevant 
title, I am closing it. [~salem-faraxen], let me know if you want to reopen and 
edit it to include any real issue.

> projet
> --
>
> Key: ZOOKEEPER-2673
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2673
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] (ZOOKEEPER-2674) Projet-Final

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro resolved ZOOKEEPER-2674.
---
Resolution: Invalid

As this issue has been open a week ago without any description or a relevant 
title, I am closing it. [~salem-faraxen], let me know if you want to reopen and 
edit it to include any real issue.

> Projet-Final
> 
>
> Key: ZOOKEEPER-2674
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2674
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ZOOKEEPER-2494) reword documentation to say "a simple shell to execute file-like operations" instead of "a shell in which to execute simple file-system-like operations"

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2494:
---

Hey [~abrahamfine], this issue looks like a nice have for 3.4.10 release! :) Do 
you plan to work on it? If not, do you mind if I submit a PR?

> reword documentation to say "a simple shell to execute file-like operations" 
> instead of "a shell in which to execute simple file-system-like operations"
> 
>
> Key: ZOOKEEPER-2494
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2494
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.4.8, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.5.3
>
>
> [~rakeshr] mades this suggestion in ZOOKEEPER-2477 and I thought this was 
> worth implementing in its own jira



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

[jira] [Commented] (ZOOKEEPER-2674) Projet-Final

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2674:
---

What is the problem [~salem-faraxen]? Can we close this?

/cc [~arshadmohammad] [~hanm]

> Projet-Final
> 
>
> Key: ZOOKEEPER-2674
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2674
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




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

[jira] [Commented] (ZOOKEEPER-2673) projet

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2673:
---

What is the problem [~salem-faraxen]? Can we close this?

/cc [~arshadmohammad] [~hanm]

> projet
> --
>
> Key: ZOOKEEPER-2673
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2673
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: berkani
>Priority: Trivial
>




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

[jira] [Commented] (ZOOKEEPER-2680) Correct DataNode.getChildren() inconsistent behavior.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2680:
---

A few comments:

{code}
private static Set EMPTY_SET = Collections.unmodifiableSet(new 
HashSet(0));
{code}

is lacking the *final* modifier. Also, it can be:

{code}
private static final Set EMPTY_SET = Collections.emptySet();
{code}

About {{DataNode.setChildren()}} (would love the comments of [~breed] and 
[~fpj], as I can be about to write something utterly stupid :o) ): 

{code}
public synchronized void setChildren(HashSet children) {
this.children = children;
}
{code}

The code above could potentially pass a null. Is this behaviour expected? Say, 
instead of providing a {{DataNode.clear()}} method we just pass 
{{DataNode.setChildren(null)}} to reset all the children? Also, passing an 
alien reference (children) that can be changed outside the scope of 
{{DataNode}} seems potentially dangerous too. IMHO, {{DataNode.setChildren}} 
could have been coded more defensively. I would have done something akin the 
code below, but *of course* performance considerations should be taken into 
account. 

{code}
public synchronized void setChildren(Set children) {
if (children == null || children.isEmpty()) // isEmpty() is optional
   return;
if (this.children == null)
   this.children = new HashSet<>(8);
this.children.addAll(children);
}

// new method
public synchronized void clear() {
 children.clear();
}
{code}

All in all, I am +1 with this patch. :) Only took the opportunity to clarify 
this {{DataNode.setChildren}} method use, but I think we can commit this patch 
without changing the method just cited.

> Correct DataNode.getChildren() inconsistent behavior.
> -
>
> Key: ZOOKEEPER-2680
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2680
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.9, 3.5.1
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2680-01.patch
>
>
> DataNode.getChildren() API returns null and empty set if there are no 
> children in it depending on when the API is called. DataNode.getChildren() 
> API behavior should be changed and it should always return empty set if the 
> node does not have any child
> *DataNode.getChildren() API Current Behavior:*
> # returns null initially
> When DataNode is created and no children are added yet, 
> DataNode.getChildren() returns null
> # returns empty set after all the children are deleted:
> created a Node
> add a child
> delete the child
> DataNode.getChildren() returns empty set.
> After fix DataNode.getChildren() should return empty set in all the above 
> cases.



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

[jira] [Commented] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2464:
---

Yeah... makes sense, it's pretty inconsistent behavior. It would require some 
defensive code as {{DataNode.setChildren(null)}} could introduce the null 
again. In fact, it is a total  refactoring of {{DataNode}}, albeit a small 
class. Wdyt [~randgalt]? 

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



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

[jira] [Commented] (ZOOKEEPER-2395) allow ant command line control of junit test jvm args

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2395:
---

oops, *excuse me* [~hanm] for skipping this comment on ZK-2664, shame on me. :(

Agree with you. 

> allow ant command line control of junit test jvm args
> -
>
> Key: ZOOKEEPER-2395
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2395
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build, tests
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.5.3, 3.6.0, 3.4.11
>
>
> We're seeing some failing jobs (see below) and the speculation is that it 
> might be due to ipv6 vs ipv4 usage. It would be nice to turn on "prefer ipv4" 
> in the jvm but there is no easy way to do that. I'll propose that we add a 
> variable to ant that's passed through to the jvm.
> 
> This is very odd. It failed 2 of the last three times it was run on H9
> with the following:
> 2016-03-20 06:06:18,480 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@74] - TEST METHOD FAILED
> testBindByAddress
> java.net.SocketException: No such device
> at java.net.NetworkInterface.isLoopback0(Native Method)
> at java.net.NetworkInterface.isLoopback(NetworkInterface.java:339)
> at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
> https://builds.apache.org/job/ZooKeeper_branch34/buildTimeTrend
> Why would it pass one of the times though if there is no loopback
> device on the host? That seems very odd!



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

[jira] [Resolved] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro resolved ZOOKEEPER-2573.
---
Resolution: Fixed

> 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
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Mohammad Arshad
>Assignee: Edward Ribeiro
> Fix For: 3.4.10, 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] [Comment Edited] (ZOOKEEPER-2646) Java target in branch 3.4 doesn't match documentation

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2646 at 1/25/17 12:39 PM:
-

[~fpj], [~hanm], Hi guys!

For whatever reason, the related PR ( 
https://github.com/apache/zookeeper/pull/127 ) was not closed even tough the PR 
was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
the PR?

Cheers!


was (Author: eribeiro):
[~fpj], [~hanm], Hi guys!

For whatever reason, this issue and related PR ( 
https://github.com/apache/zookeeper/pull/127 ) were not closed even tough the 
PR was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
both (JIRA and PR)?

Cheers!

> Java target in branch 3.4 doesn't match documentation 
> --
>
> Key: ZOOKEEPER-2646
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2646
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.10
>
>
> Need to update build.xml 1.5->1.6.



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

[jira] [Commented] (ZOOKEEPER-2646) Java target in branch 3.4 doesn't match documentation

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2646:
---

[~fpj], [~hanm], Hi guys!

For whatever reason, this issue and related PR ( 
https://github.com/apache/zookeeper/pull/127 ) were not closed even tough the 
PR was merged into branch-3.4: 
https://github.com/apache/zookeeper/commit/7fd0884b0d6577162d71aedc460a588576cd483a

Flavio, only you or INFRA can close the GH PR, afaik. Would you mind to close 
both (JIRA and PR)?

Cheers!

> Java target in branch 3.4 doesn't match documentation 
> --
>
> Key: ZOOKEEPER-2646
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2646
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
> Fix For: 3.4.10
>
>
> Need to update build.xml 1.5->1.6.



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

[jira] [Commented] (ZOOKEEPER-2395) allow ant command line control of junit test jvm args

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2395:
---

[~hanm], is this issue a duplicate of ZOOKEEPER-2664? I think so, and if I am 
right we should close it, right? Do you agree [~phunt]?

> allow ant command line control of junit test jvm args
> -
>
> Key: ZOOKEEPER-2395
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2395
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: build, tests
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> We're seeing some failing jobs (see below) and the speculation is that it 
> might be due to ipv6 vs ipv4 usage. It would be nice to turn on "prefer ipv4" 
> in the jvm but there is no easy way to do that. I'll propose that we add a 
> variable to ant that's passed through to the jvm.
> 
> This is very odd. It failed 2 of the last three times it was run on H9
> with the following:
> 2016-03-20 06:06:18,480 [myid:] - INFO
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@74] - TEST METHOD FAILED
> testBindByAddress
> java.net.SocketException: No such device
> at java.net.NetworkInterface.isLoopback0(Native Method)
> at java.net.NetworkInterface.isLoopback(NetworkInterface.java:339)
> at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
> https://builds.apache.org/job/ZooKeeper_branch34/buildTimeTrend
> Why would it pass one of the times though if there is no loopback
> device on the host? That seems very odd!



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

[jira] [Updated] (ZOOKEEPER-2676) Enable remote debugging unit tests on CLI

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2676:
--
Description: 
Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDE to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.

  was:
Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDEA to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.


> Enable remote debugging unit tests on CLI
> -
>
> Key: ZOOKEEPER-2676
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2676
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
>
> Sometimes it's useful to be able to run a unit test from the CLI and then 
> attach an IDE to enable debugging as below:
> {code}
> $ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
> {code}
> The unit test will stop as below:
> {code}
> (...)
> junit.run-concurrent:
>  [echo] Running 1 concurrent JUnit processes. 
> [junit] Listening for transport dt_socket at address: 5005
> {code}
> And we will be able to put breakpoints on the target class and bind the IDE 
> to it's process to step through the test.



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

[jira] [Created] (ZOOKEEPER-2676) Enable remote debugging unit tests on CLI

[Edward Ribeiro (JIRA)]

Edward Ribeiro created ZOOKEEPER-2676:
-

 Summary: Enable remote debugging unit tests on CLI
 Key: ZOOKEEPER-2676
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2676
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Minor


Sometimes it's useful to be able to run a unit test from the CLI and then 
attach an IDEA to enable debugging as below:

{code}
$ ant -Dtestcase=FourLetterWordsTest -DremoteDebug=true test-core-java
{code}

The unit test will stop as below:

{code}
(...)
junit.run-concurrent:
 [echo] Running 1 concurrent JUnit processes. 
[junit] Listening for transport dt_socket at address: 5005
{code}

And we will be able to put breakpoints on the target class and bind the IDE to 
it's process to step through the test.



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

[jira] [Created] (ZOOKEEPER-2675) Bump Mockito to version 2

[Edward Ribeiro (JIRA)]

Edward Ribeiro created ZOOKEEPER-2675:
-

 Summary: Bump Mockito to version 2
 Key: ZOOKEEPER-2675
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2675
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Trivial


Current mockito version is 1.8.2, but version 2 brings new improvements while 
keeping backwards compatibility to jdk6 (branch-3.4) and support partially 
jdk8. So, this issue is to bring mockito version up to date.



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

[jira] [Comment Edited] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2464 at 1/25/17 9:54 AM:


+1, LGTM.

Hey, [~randgalt], I have just seen that ZK projects imports mockito framework 
but only uses it on a single test case (as far as my quick-and-dirty search 
showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?


was (Author: eribeiro):
+1, lgtm. Hey, [~randgalt], I have just seen that ZK projects imports mockito 
framework but only uses it on a single test case (as far as my quick-and-dirty 
search showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



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

[jira] [Updated] (ZOOKEEPER-2464) NullPointerException on ContainerManager

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2464:
--
Attachment: ContainerManagerTest.java

+1, lgtm. Hey, [~randgalt], I have just seen that ZK projects imports mockito 
framework but only uses it on a single test case (as far as my quick-and-dirty 
search showed).

*If you want to add a test case to this bug*, then I am attaching a class that 
can be uses mockito to do so. If you decide it's too much boilerplate for 
little benefit then no problem leaving it out of this patch. *It's up to you to 
include it or not, just an idea*. :)

In either case, we are good to go with this patch, IMHO. Please, any committer 
would mind to merge it as soon as possible?

/cc [~hanm], [~arshadmohammad]?

> NullPointerException on ContainerManager
> 
>
> Key: ZOOKEEPER-2464
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2464
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Stefano Salmaso
>Assignee: Jordan Zimmerman
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ContainerManagerTest.java, ZOOKEEPER-2464.patch
>
>
> I would like to expose you to a problem that we are experiencing.
> We are using a cluster of 7 zookeeper and we use them to implement a 
> distributed lock using Curator 
> (http://curator.apache.org/curator-recipes/shared-reentrant-lock.html)
> So .. we tried to play with the servers to see if everything worked properly 
> and we stopped and start servers to see that the system worked well
> (like stop 03, stop 05, stop 06, start 05, start 06, start 03)
> We saw a strange behavior.
> The number of znodes grew up without stopping (normally we had 4000 or 5000, 
> we got to 60,000 and then we stopped our application)
> In zookeeeper logs I saw this (on leader only, one every minute)
> 2016-07-04 14:53:50,302 [myid:7] - ERROR 
> [ContainerManagerTask:ContainerManager$1@84] - Error checking containers
> java.lang.NullPointerException
>at 
> org.apache.zookeeper.server.ContainerManager.getCandidates(ContainerManager.java:151)
>at 
> org.apache.zookeeper.server.ContainerManager.checkContainers(ContainerManager.java:111)
>at 
> org.apache.zookeeper.server.ContainerManager$1.run(ContainerManager.java:78)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> We have not yet deleted the data ... so the problem can be reproduced on our 
> servers



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

[jira] [Commented] (ZOOKEEPER-2359) ZooKeeper client has unnecessary logs for watcher removal errors

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2359:
---

+1, lgtm. Please, [~hanm] and/or [~arshadmohammad], could you please take a 
look? :) 

[~randgalt], those changes need to be applied to {{master}} and {{branch-3.5}}, 
right? Didn't find on {{branch-3.4}}...

> ZooKeeper client has unnecessary logs for watcher removal errors
> 
>
> Key: ZOOKEEPER-2359
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2359
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client
>Affects Versions: 3.5.1
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Attachments: ZOOKEEPER-2359.patch
>
>
> ClientCnxn.java logs errors during watcher removal:
> LOG.error("Failed to find watcher!", nwe);
> LOG.error("Exception when removing watcher", ke);
> An error code/exception is generated so the logs are noisy and unnecessary. 
> If the client handles the error there's still a log message. This is 
> different than other APIs. These logs should be removed.



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

[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2671:
---

The new method is the only change from ZK-2508 that we need to backport to 
branch-3.4???

I don't have time to look at the whole changeset now...

Best regards
 

> 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] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2671:
---

Excuse me, you right [~rakeshr]! 

BTW, the error is reproducible with {{ant test compile}} and {{ant tar}}. As I 
could see, the ClientBase's method signature lacking on branch-3.4 was 
introduced by ZOOKEEPER-2508 (commit: 685a5268).

> 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] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2664:
---

[~hanm], does this issue duplicates ZOOKEEPER-2395? Could you close that one 
too?

> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



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

[jira] [Commented] (ZOOKEEPER-2671) Compilation error in branch-3.4

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2671:
---

[~arshad.mohammad], do you see this error on your local dev environment or 
jenkins CI?

I've just pulled the latest commit from branch-3.4 
(e93d5b27f1cc2c66df39b45be321e90c798bdc9b) and was able to {{ant clean 
compile}} on my laptop.

> 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] [Commented] (ZOOKEEPER-2670) CLONE - Connections fo ZooKeeper server becomes slow over time with native GSSAPI

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2670:
---

Hey [~fittey], thanks for taking a stab at this issue. But cloning an issue is 
not the way we work here, AFAIK. 

First, we are switching to a Github based workflow, so you can clone the ZK 
repo from GH, make the changes in your branch and then submit as a PR to ZK at 
GH. So, attaching is not even required anymore. More details here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Second, it would be nice if you could sync with the current  ZOOKEEPER-2230 
assignee so that you can discuss and decide for a solution that covers both 
cases. In any case, the committers will have the final word and can decide what 
could fits bets to merge.

So, no need yet another JIRA issue to address the same problem. Please, close 
this one and discuss your solution (pinging committers if necessary) at  
ZOOKEEPER-2230. 

Best Regards!

> CLONE - Connections fo ZooKeeper server becomes slow over time with native 
> GSSAPI
> -
>
> Key: ZOOKEEPER-2670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2670
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6, 3.4.7, 3.4.8, 3.5.0
> Environment: OS: RHEL6
> Java: 1.8.0_40
> Configuration:
> java.env:
> {noformat}
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Xmx5120m"
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS 
> -Djava.security.auth.login.config=/local/apps/zookeeper-test1/conf/jaas-server.conf"
> SERVER_JVMFLAGS="$SERVER_JVMFLAGS -Dsun.security.jgss.native=true"
> {noformat}
> jaas-server.conf:
> {noformat}
> Server {
> com.sun.security.auth.module.Krb5LoginModule required
> useKeyTab=true
> isInitiator=false
> principal="zookeeper/@";
> };
> {noformat}
> Process environment:
> {noformat}
> KRB5_KTNAME=/local/apps/zookeeper-test1/conf/keytab
> ZOO_LOG_DIR=/local/apps/zookeeper-test1/log
> ZOOCFGDIR=/local/apps/zookeeper-test1/conf
> {noformat}
>Reporter: Yan Fitterer
>Assignee: Enis Soztutar
>  Labels: patch
> Fix For: 3.4.6, 3.4.7, 3.4.8, 3.5.2
>
>
> ZooKeeper server becomes slow over time when native GSSAPI is used. The 
> connection to the server starts taking upto 10 seconds.
> This is happening with ZooKeeper-3.4.6 and is fairly reproducible.
> Debug logs:
> {noformat}
> 2015-07-02 00:58:49,318 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:NIOServerCnxnFactory@197] - 
> Accepted socket connection from /:47942
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@78] - 
> serviceHostname is ''
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@79] - 
> servicePrincipalName is 'zookeeper'
> 2015-07-02 00:58:49,318 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@80] - SASL 
> mechanism(mech) is 'GSSAPI'
> 2015-07-02 00:58:49,324 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperSaslServer@106] - Added 
> private credential to subject: [GSSCredential: 
> zookeeper@ 1.2.840.113554.1.2.2 Accept [class 
> sun.security.jgss.wrapper.GSSCredElement]]
> 2015-07-02 00:58:59,441 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@810] - Session 
> establishment request from client /:47942 client's lastZxid is 0x0
> 2015-07-02 00:58:59,441 [myid:] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@868] - Client 
> attempting to establish new session at /:47942
> 2015-07-02 00:58:59,448 [myid:] - DEBUG 
> [SyncThread:0:FinalRequestProcessor@88] - Processing request:: 
> sessionid:0x14e486028785c81 type:createSession cxid:0x0 zxid:0x110e79 
> txntype:-10 reqpath:n/a
> 2015-07-02 00:58:59,448 [myid:] - DEBUG 
> [SyncThread:0:FinalRequestProcessor@160] - sessionid:0x14e486028785c81 
> type:createSession cxid:0x0 zxid:0x110e79 txntype:-10 reqpath:n/a
> 2015-07-02 00:58:59,448 [myid:] - INFO  [SyncThread:0:ZooKeeperServer@617] - 
> Established session 0x14e486028785c81 with negotiated timeout 1 for 
> client /:47942
> 2015-07-02 00:58:59,452 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@949] - Responding 
> to client SASL token.
> 2015-07-02 00:58:59,452 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@953] - Size of 
> client SASL token: 706
> 2015-07-02 00:58:59,460 [myid:] - DEBUG 
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:42405:ZooKeeperServer@984] - Size of 
> server SASL response: 161
> 2015-07-02 00:58:59,462 [myid:] - DEBUG 
> 

[jira] [Commented] (ZOOKEEPER-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Cool, [~praste]! 

After my comment, I remembered that there was some work on Log4j done by 
[~arshad.mohammad] last year. Please, catch up with the following JIRAS:

https://issues.apache.org/jira/browse/ZOOKEEPER-2393

https://issues.apache.org/jira/browse/ZOOKEEPER-1371

Furthermore, this issue seems like a duplicate of 
https://issues.apache.org/jira/browse/ZOOKEEPER-2342 so I would advise you to 
ping [~cnauroth], so that you don't work on the same thing and catch up with 
the discussion there too.

Cheers! 


> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



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

[jira] [Updated] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2573:
--
Affects Version/s: 3.4.9
   3.5.2

> 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
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Edward Ribeiro
> Fix For: 3.4.10, 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] [Updated] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2573:
--
Fix Version/s: 3.4.10

> 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
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Arshad Mohammad
>Assignee: Edward Ribeiro
> Fix For: 3.4.10, 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-2659) Use log4j2 as a logging framework as log4j 1.X is now deprecated

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2659:
---

Thanks for taking a stab at this issue, [~praste]! 

The ZK project is switching to a Github based workflow so that it can be easier 
for contributors to submit patches and reviewers to take a look at the patch. 
Would you mind to submit a PR for this issue? your PR title should start as 
"ZOOKEEPER-2664:" so that it can automatically be linked to this JIRA issue. 
More details here under 'Pull requests via github (work in progress)' here 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Best regards,
Edward

> Use log4j2 as a logging framework as log4j 1.X is now deprecated
> 
>
> Key: ZOOKEEPER-2659
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2659
> Project: ZooKeeper
>  Issue Type: Wish
>Reporter: Pushkar Raste
>Priority: Minor
> Attachments: zk_log4j2_migration.patch
>
>
> Zookeeper currently uses {{log4j 1.X}} as the default logging framework. 
> {{log4j 1.X}} is now deprecated http://logging.apache.org/log4j/1.2/
> This ticket is to track efforts to move zookeeper to {{log4j2}}



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

[jira] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2664:
---

Hi [~tedyu],

Thanks for the patch! :) The ZK project is switching to a Github based workflow 
so that it can be easier for contributors to submit PR and reviewers to take a 
look at the patch. Would you mind to submit a PR for this issue? your PR title 
should start as "ZOOKEEPER-2664:" so that it can automatically be linked to 
this JIRA issue. More details here under 'Pull requests via github (work in 
progress)' here 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute 

Secondly, this issue is a duplicate of 
https://issues.apache.org/jira/browse/ZOOKEEPER-2395 , I am marking it as so, 
but leave to [~phunt] to decide which one to keep and which one to close, but 
merging the comments & proposed solutions from both, of course.

Thirdly, I couldn't patch the file using both commands below. Are you sure you 
generated the patch with the command like:  {{git diff --no-prefix 
previous_commit..your_commit > ZOOKEEPER-2664.patch}} ?

Finally, would you mind to LOG a WARN message inside the catch block so that 
whoever looks at the log knows that this test was skipped because it had 
trouble finding the loopback interface?

Thanks


> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch 

[jira] [Issue Comment Deleted] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2664:
--
Comment: was deleted

(was: Hi [~ted_yu]
)

> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



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

[jira] [Commented] (ZOOKEEPER-2664) ClientPortBindTest#testBindByAddress may fail due to "No such device" exception

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2664:
---

Hi [~ted_yu]


> ClientPortBindTest#testBindByAddress may fail due to "No such device" 
> exception
> ---
>
> Key: ZOOKEEPER-2664
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2664
> Project: ZooKeeper
>  Issue Type: Test
>Affects Versions: 3.4.6
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: ZOOKEEPER-2664.v1.txt
>
>
> Saw the following in a recent run:
> {code}
> Stacktrace
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
> Standard Output
> 2017-01-12 23:20:43,792 [myid:] - INFO  [main:ZKTestCase$1@50] - STARTING 
> testBindByAddress
> 2017-01-12 23:20:43,795 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@50] - RUNNING TEST METHOD 
> testBindByAddress
> 2017-01-12 23:20:43,799 [myid:] - INFO  
> [main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED 
> testBindByAddress
> java.net.SocketException: No such device
>   at java.net.NetworkInterface.isLoopback0(Native Method)
>   at java.net.NetworkInterface.isLoopback(NetworkInterface.java:390)
>   at 
> org.apache.zookeeper.test.ClientPortBindTest.testBindByAddress(ClientPortBindTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>   at 
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
>   at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>   at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:532)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1179)
>   at 
> org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:1030)
> {code}
> Proposed fix is to catch exception from isLoopback() call.



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

[jira] [Commented] (ZOOKEEPER-261) Reinitialized servers should not participate in leader election

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-261:
--

I wrote the comment below on GH, but for whatever reason it was not posted 
here, so I am duplicating just to see where/if I am mistaken. :)

"Hi @enixon,

I think your approach is very cool, for real. I only had time to give a first 
pass on your patch now (hope to look closer soon, esp. the tests), but I would 
like to ask a dumb question.

What if we change the approach and, instead of the initialize file being used 
for normal execution, we use a recover (or rejoin) file whose presence denote 
an exceptional restart of a ZK node? That way, if and only if, this file is 
present we delete it and return -1L so that it cannot take part in the 
elections until it catches up with the ensemble, etc.

If this file is not present then we proceed as usual (i.e. returns 0L). This 
way, we are dealing with the exceptional case by using the initialize/recover. 
For example: node C (from a 3 node ensemble) crashes due to disk full 
exceptions. Then the operator delete the data/ directory and put the recovering 
file there.

In my humble (and naive) option, it would avoid some headaches for ops people 
who would forget to include the initialize file in a node or two, during 
rolling upgrades or other cases I can't think of right now. The presence of 
this file for normal execution changes the ordinal operation of a ZK node. So, 
we don't have to deal with changing the standard way of starting a ZK node. The 
recover file is for exceptional cases, where we want to make sure the 
restarting node cannot take part in an election.

PS: I didn't get the autocreateDB stuff also. But it's late at night here. 

Wdyt?

/cc [~hanm] [~breed] [~fpj]
"

PS2: The scenario described in the JIRA is a good point in favor of a 
{{initialize}} file, because when B & C came back **automatically** then the 
{{initialize}} file would be missing from both nodes, and the ensemble would 
grind to a halt because no one would be leader, right? Otherwise, if there was 
an script to **automatically* create those files on each node  once the machine 
was turned up then B & C would have the file created and then we could come 
back to square one, right? Does it make any sense what I am writing? Please, 
lecture me. :)

> Reinitialized servers should not participate in leader election
> ---
>
> Key: ZOOKEEPER-261
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-261
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: leaderElection, quorum
>Reporter: Benjamin Reed
>
> A server that has lost its data should not participate in leader election 
> until it has resynced with a leader. Our leader election algorithm and 
> NEW_LEADER commit assumes that the followers voting on a leader have not lost 
> any of their data. We should have a flag in the data directory saying whether 
> or not the data is preserved so that the the flag will be cleared if the data 
> is ever cleared.
> Here is the problematic scenario: you have have ensemble of machines A, B, 
> and C. C is down. the last transaction seen by C is z. a transaction, z+1, is 
> committed on A and B. Now there is a power outage. B's data gets 
> reinitialized. when power comes back up, B and C comes up, but A does not. C 
> will be elected leader and transaction z+1 is lost. (note, this can happen 
> even if all three machines are up and C just responds quickly. in that case C 
> would tell A to truncate z+1 from its log.) in theory we haven't violated our 
> 2f+1 guarantee, since A is failed and B still hasn't recovered from failure, 
> but it would be nice if when we don't have quorum that system stops working 
> rather than works incorrectly if we lose quorum.



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

[jira] [Comment Edited] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2573 at 12/28/16 5:33 PM:
-

Hi [~arshad.mohammad] and [~hanm], I hope you don't mind, but I decided to take 
a stab at this issue. I would be really glad if you could test it, mainly in a 
Windows env, that I don't have access. :(

One minor issue I faced is that I think we could use the first 8 characters of 
the git SHA-1. On unix-like plataforms this is straighforward, just a matter of 
adding a call to {{cut}} command as below: 

{code}
git rev-parse HEAD | cut -c1-8
{code}

The problem is that on Windows there's no equivalent to {{cut}}, and it seemed 
cumbersome to add an equivalent. So, I left the full sha1 code as of now:

{code}
git rev-parse HEAD
{code}

**The patch is target at branch-3.4, but I was able to cherry-pick the commit 
to branch-3.5 and master**.

[~breed], [~phunt], and [~fpj], could you also see if the patch is okay, please?

Thanks!


was (Author: eribeiro):
Hi [~arshad.mohammad] and [~hanm], I hope you don't mind, but I decided to take 
a stab at this issue. I would be really glad if you could test it, mainly in a 
Windows env, that I don't have access. :(

One minor issue I faced is that I think we could use the first 8 characters of 
the git SHA-1. On unix-like plataforms this is straighforward, just a matter of 
adding a call to {{cut}} command as below: 

{code}
git rev-parse HEAD | cut -c1-8
{code}

The problem is that on Windows there's no equivalent to {{cut}}, and it seemed 
cumbersome to add an equivalent. So, I left the full sha1 code as of now:

{code}
git rev-parse HEAD
{code}

[~breed], [~phunt], and [~fpj], could you also see if the patch is okay, please?

Thanks!

> 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
>Assignee: Edward Ribeiro
> 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-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2573:
---

Hi [~arshad.mohammad] and [~hanm], I hope you don't mind, but I decided to take 
a stab at this issue. I would be really glad if you could test it, mainly in a 
Windows env, that I don't have access. :(

One minor issue I faced is that I think we could use the first 8 characters of 
the git SHA-1. On unix-like plataforms this is straighforward, just a matter of 
adding a call to {{cut}} command as below: 

{code}
git rev-parse HEAD | cut -c1-8
{code}

The problem is that on Windows there's no equivalent to {{cut}}, and it seemed 
cumbersome to add an equivalent. So, I left the full sha1 code as of now:

{code}
git rev-parse HEAD
{code}

[~breed], [~phunt], and [~fpj], could you also see if the patch is okay, please?

Thanks!

> 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
>Assignee: Edward Ribeiro
> 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] [Assigned] (ZOOKEEPER-2573) Modify Info.REVISION to adapt git repo

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro reassigned ZOOKEEPER-2573:
-

Assignee: Edward Ribeiro

> 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
>Assignee: Edward Ribeiro
> 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-1364) Add orthogonal fault injection mechanism/framework

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-1364:
---

+1 about merging ZOOKEEPER-2549 first, [~hanm]!

> Add orthogonal fault injection mechanism/framework
> --
>
> Key: ZOOKEEPER-1364
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1364
> Project: ZooKeeper
>  Issue Type: Test
>  Components: tests
>Reporter: Andrei Savu
>Assignee: Andrei Savu
>
> Hadoop has a mechanism for doing fault injection (HDFS-435). I think it would 
> be useful if something similar would be available for ZooKeeper. 



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

[jira] [Commented] (ZOOKEEPER-1416) Persistent Recursive Watch

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-1416:
---

My two cents: to leave as is would be **very** nice, but I am afraid only 
having NodeCreated/NodeDeleted would be better option because persistent watch 
is recursive anyway and due to scaling issues (thousands of children node 
changes, each firing 2 events). So, if we could cut the number of events in 
half it could be better, *imho* (excuse me if I misunderstood the question).

[~fpj], [~hanm], [~phunt], wdyt?

> Persistent Recursive Watch
> --
>
> Key: ZOOKEEPER-1416
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1416
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: c client, documentation, java client, server
>Reporter: Phillip Liu
>Assignee: Jordan Zimmerman
> Attachments: ZOOKEEPER-1416.patch, ZOOKEEPER-1416.patch
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> h4. The Problem
> A ZooKeeper Watch can be placed on a single znode and when the znode changes 
> a Watch event is sent to the client. If there are thousands of znodes being 
> watched, when a client (re)connect, it would have to send thousands of watch 
> requests. At Facebook, we have this problem storing information for thousands 
> of db shards. Consequently a naming service that consumes the db shard 
> definition issues thousands of watch requests each time the service starts 
> and changes client watcher.
> h4. Proposed Solution
> We add the notion of a Persistent Recursive Watch in ZooKeeper. Persistent 
> means no Watch reset is necessary after a watch-fire. Recursive means the 
> Watch applies to the node and descendant nodes. A Persistent Recursive Watch 
> behaves as follows:
> # Recursive Watch supports all Watch semantics: CHILDREN, DATA, and EXISTS.
> # CHILDREN and DATA Recursive Watches can be placed on any znode.
> # EXISTS Recursive Watches can be placed on any path.
> # A Recursive Watch behaves like a auto-watch registrar on the server side. 
> Setting a  Recursive Watch means to set watches on all descendant znodes.
> # When a watch on a descendant fires, no subsequent event is fired until a 
> corresponding getData(..) on the znode is called, then Recursive Watch 
> automically apply the watch on the znode. This maintains the existing Watch 
> semantic on an individual znode.
> # A Recursive Watch overrides any watches placed on a descendant znode. 
> Practically this means the Recursive Watch Watcher callback is the one 
> receiving the event and event is delivered exactly once.
> A goal here is to reduce the number of semantic changes. The guarantee of no 
> intermediate watch event until data is read will be maintained. The only 
> difference is we will automatically re-add the watch after read. At the same 
> time we add the convience of reducing the need to add multiple watches for 
> sibling znodes and in turn reduce the number of watch messages sent from the 
> client to the server.
> There are some implementation details that needs to be hashed out. Initial 
> thinking is to have the Recursive Watch create per-node watches. This will 
> cause a lot of watches to be created on the server side. Currently, each 
> watch is stored as a single bit in a bit set relative to a session - up to 3 
> bits per client per znode. If there are 100m znodes with 100k clients, each 
> watching all nodes, then this strategy will consume approximately 3.75TB of 
> ram distributed across all Observers. Seems expensive.
> Alternatively, a blacklist of paths to not send Watches regardless of Watch 
> setting can be set each time a watch event from a Recursive Watch is fired. 
> The memory utilization is relative to the number of outstanding reads and at 
> worst case it's 1/3 * 3.75TB using the parameters given above.
> Otherwise, a relaxation of no intermediate watch event until read guarantee 
> is required. If the server can send watch events regardless of one has 
> already been fired without corresponding read, then the server can simply 
> fire watch events without tracking.



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

[jira] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2465:
---

hey [~cnauroth] and [~fpj], sorry taking too much time procrastinating on this 
issue. According the fruitful discussions we had back in September, 2016 (link 
provided by Flavio above), I have removed the date from copyright notices on 
current docs as well as in template XML that generates the HTML and PDFs. See 
if you agree, please.

> Documentation copyright notice is out of date.
> --
>
> Key: ZOOKEEPER-2465
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2465
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Chris Nauroth
>Assignee: Edward Ribeiro
>Priority: Blocker
> Fix For: 3.5.3
>
> Attachments: ZOOKEEPER-2465.2.patch, ZOOKEEPER-2465.patch
>
>
> As reported by [~eribeiro], all of the documentation pages show a copyright 
> notice dating "2008-2013".  This issue tracks updating the copyright notice 
> on all documentation pages to show the current year.



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

[jira] [Updated] (ZOOKEEPER-2644) contrib/rest does not include rest.sh when packaged

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2644:
--
Assignee: Edward Ribeiro

> contrib/rest does not include rest.sh when packaged
> ---
>
> Key: ZOOKEEPER-2644
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2644
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Minoru Osuka
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2644.patch
>
>
> contrib/rest does not include rest.sh when packaged. I propose to add rest.sh 
> into tar.gz that it make ZooKeeper REST easier to use.



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

[jira] [Updated] (ZOOKEEPER-2644) contrib/rest does not include rest.sh when packaged

[Edward Ribeiro (JIRA)]

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

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

> contrib/rest does not include rest.sh when packaged
> ---
>
> Key: ZOOKEEPER-2644
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2644
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Minoru Osuka
>Priority: Minor
> Attachments: ZOOKEEPER-2644.patch
>
>
> contrib/rest does not include rest.sh when packaged. I propose to add rest.sh 
> into tar.gz that it make ZooKeeper REST easier to use.



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

[jira] [Comment Edited] (ZOOKEEPER-2644) contrib/rest does not include rest.sh when packaged

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro edited comment on ZOOKEEPER-2644 at 12/15/16 4:00 PM:
-

Hi, [~minoru], thanks for the patch! 

FYI, the ZK community is transitioning to a Github based contribution workflow, 
so would you mind to open a Pull Request on this issue? More instructions here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Cheers!


was (Author: eribeiro):
Hi, [~minoru], thanks for the patch! 

FYI, the ZK community is moving to a Github based contributions, so you would 
mind to open a Pull Request on this issue? More instructions here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Cheers!

> contrib/rest does not include rest.sh when packaged
> ---
>
> Key: ZOOKEEPER-2644
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2644
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Minoru Osuka
>Priority: Minor
> Attachments: ZOOKEEPER-2644.patch
>
>
> contrib/rest does not include rest.sh when packaged. I propose to add rest.sh 
> into tar.gz that it make ZooKeeper REST easier to use.



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

[jira] [Commented] (ZOOKEEPER-2644) contrib/rest does not include rest.sh when packaged

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2644:
---

Hi, [~minoru], thanks for the patch! 

FYI, the ZK community is moving to a Github based contributions, so you would 
mind to open a Pull Request on this issue? More instructions here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

Cheers!

> contrib/rest does not include rest.sh when packaged
> ---
>
> Key: ZOOKEEPER-2644
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2644
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: contrib
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Minoru Osuka
>Priority: Minor
> Attachments: ZOOKEEPER-2644.patch
>
>
> contrib/rest does not include rest.sh when packaged. I propose to add rest.sh 
> into tar.gz that it make ZooKeeper REST easier to use.



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

[jira] [Commented] (ZOOKEEPER-2470) ServerConfig#parse(String[]) ignores tickTime

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2470:
---

I had an email chat with @shralex and he said I could get this issue to push 
forward. Even though the issue is *quite trivial*, I've got in touch with him 
because it would be really important to have this bug fixed for 3.4, 3.5 and 
master branches asap.


> ServerConfig#parse(String[])  ignores tickTime
> --
>
> Key: ZOOKEEPER-2470
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2470
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Alexander Shraer
>Assignee: Edward Ribeiro
>Priority: Trivial
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2470.patch
>
>
> Based on bug report from ykgarfield:
> ServerConfig#parse(String[]) method has the following code:
> public void parse(String[] args) {
> ...
> if (args.length == 3) {
> tickTime = Integer.parseInt(args[2]);
> }
> if (args.length == 4) {
> maxClientCnxns = Integer.parseInt(args[3]);
> }
> }
> ```
> So if args.length == 4 tickTime isn't parsed.



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

[jira] [Assigned] (ZOOKEEPER-2470) ServerConfig#parse(String[]) ignores tickTime

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro reassigned ZOOKEEPER-2470:
-

Assignee: Edward Ribeiro  (was: Alexander Shraer)

> ServerConfig#parse(String[])  ignores tickTime
> --
>
> Key: ZOOKEEPER-2470
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2470
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Alexander Shraer
>Assignee: Edward Ribeiro
>Priority: Trivial
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2470.patch
>
>
> Based on bug report from ykgarfield:
> ServerConfig#parse(String[]) method has the following code:
> public void parse(String[] args) {
> ...
> if (args.length == 3) {
> tickTime = Integer.parseInt(args[2]);
> }
> if (args.length == 4) {
> maxClientCnxns = Integer.parseInt(args[3]);
> }
> }
> ```
> So if args.length == 4 tickTime isn't parsed.



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

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

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2251:
---

AFAIK, if the JIRA issue states that it fixes 3.4.10, 3.5.3, and 3.6.0 then you 
should point to the earliest branch (branch-3.4). When applying the PR the 
committer can port it to branch-3.5 and master. By the way, I advise you to see 
if the patch applies cleanly on branch-3.4, branch-3.5 and master so you can 
save committer time (that is scarce) from having to deal with conflicts. ;)

_Please_, correct me if I am wrong, [~fpj], [~rgs], [~breed]. :)

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



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

[jira] [Commented] (ZOOKEEPER-2565) listquota should display the quota even it is set on parent/child node

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2565:
---

Sure! :) Make sure you open a Github Pull Request with the same title as the 
issue you are working on.

Further instructions here: 
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

> listquota  should display the quota even it is set on parent/child node
> -
>
> Key: ZOOKEEPER-2565
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2565
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>Assignee: Rakesh Kumar Singh
>Priority: Minor
>
> listquota  should display the quota even it is set on parent/child 
> node. As of now if we have a parent-child hierarchy for example n1->n2->n3 
> and quota is set for n2. If we try to get quota details on n1 and n3 using 
> listquota, it says no quota set but if try to set the quota on those nodes it 
> fails saying quota is already set on parent node...
> So listquota should fetch the quota set on any node in hierarchy with exact 
> path (on which quota is set) even though this api is called on any other node 
> in that hierarchy.



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

[jira] [Created] (ZOOKEEPER-2632) Add option to inform JIRA_PASSWORD at CLI prompt

[Edward Ribeiro (JIRA)]

Edward Ribeiro created ZOOKEEPER-2632:
-

 Summary: Add option to inform JIRA_PASSWORD at CLI prompt 
 Key: ZOOKEEPER-2632
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2632
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Priority: Trivial


Adds the option to prompt for the JIRA password if JIRA_USERNAME is set, but 
JIRA_PASSWORD is not. Also, asks if the user wants to continue the merge 
process if the python jira lib is not installed.



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

[jira] [Commented] (ZOOKEEPER-2470) ServerConfig#parse(String[]) ignores tickTime

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2470:
---

Hey [~shralex], it would be really cool if we got this patch patch merged. :) 
Would you mind to open a Github PR with your patch and maybe close the 
https://github.com/apache/zookeeper/pull/74 (it was the original solution as 
you pointed out at ZOOKEEPER-2472, but the PR looks fishy...)

Cheers!

> ServerConfig#parse(String[])  ignores tickTime
> --
>
> Key: ZOOKEEPER-2470
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2470
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
>Priority: Trivial
> Fix For: 3.4.10, 3.5.3
>
> Attachments: ZOOKEEPER-2470.patch
>
>
> Based on bug report from ykgarfield:
> ServerConfig#parse(String[]) method has the following code:
> public void parse(String[] args) {
> ...
> if (args.length == 3) {
> tickTime = Integer.parseInt(args[2]);
> }
> if (args.length == 4) {
> maxClientCnxns = Integer.parseInt(args[3]);
> }
> }
> ```
> So if args.length == 4 tickTime isn't parsed.



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

[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2597:
--
Attachment: ZOOKEEPER-2597.patch

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch, ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2597:
--
Attachment: (was: 85.diff)

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2597:
--
Attachment: (was: 85.2.diff)

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2597:
--
Attachment: 85.2.diff

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: 85.2.diff, 85.diff, ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro updated ZOOKEEPER-2597:
--
Attachment: 85.diff

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: 85.diff, ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

Thanks Michael! :)



On Wed, Oct 26, 2016 at 3:51 PM, ASF GitHub Bot (JIRA) 



> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

Cool! :) Thanks for reviewing and testing. I am gonna update the docs and 
document those issues.

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

I am already drafting some notes at 
https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrqXg3urw4Hm7KirQDpPIU/edit?usp=sharing
 

Should be finished before the commit. :)

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

Hi [~breed],

I have added some extra checks in the Python script as per your previous review 
comments. Wdyt?

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2617) minor typos in the source

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2617:
---

+1, thanks for the patch! :)

> minor typos in the source
> -
>
> Key: ZOOKEEPER-2617
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2617
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: tony mancill
>Priority: Trivial
>  Labels: newbie, patch
> Attachments: JIRA-ZOOKEEPER-2617.patch
>
>
> While working on the Debian packaging of ZooKeeper, some misspellings were 
> detected in the source that affect the documentation, logging, and program 
> output.
> There is a PR against github containing the patch here:  
> https://github.com/apache/zookeeper/pull/87



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

I am resuming today, should update the PR really soon.

[~breed], let me know if you have further suggestions, please. I am gonna hurry 
up with your review points. Thanks. PS: do you agree with my comments about the 
merge vs cherry-pick usage in the PR? Does it make sense?

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2614) Port ZOOKEEPER-1576 to branch3.4

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2614:
---

Yup, my fault. I should have checked it was backported to 3.4 back then (it's 
an old patch). Any committer can check and commit [~vishk] patch, please?

It LGTM, but a second opinion would be great. Thanks!

> Port ZOOKEEPER-1576 to branch3.4
> 
>
> Key: ZOOKEEPER-2614
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2614
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2614.branch-3.4.00.patch
>
>
> ZOOKEEPER-1576 handles UnknownHostException and it good to have this change 
> for 3.4 branch as well. Porting the changes to 3.4 after resolving the 
> conflicts



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

[jira] [Commented] (ZOOKEEPER-2615) Zookeeper server holds onto dead/expired session ids in the watch data structures

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2615:
---

https://issues.apache.org/jira/plugins/servlet/mobile#issue/ZOOKEEPER-2358

The issue above addresses Netty issue.

> Zookeeper server holds onto dead/expired session ids in the watch data 
> structures
> -
>
> Key: ZOOKEEPER-2615
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2615
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: guoping.gp
>Assignee: Camille Fournier
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> The same issue (https://issues.apache.org/jira/browse/ZOOKEEPER-1382) still 
> can be found even with zookeeper 3.4.6.
> this issue cause our production zookeeper cluster leak about 1 million 
> watchs, after restart the server one by one, the watch count decrease to only 
> about 4.
> I can reproduce the issue on my mac,here it is:
> 
> pguodeMacBook-Air:bin pguo$ echo srvr | nc localhost 6181
> Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT
> Latency min/avg/max: 0/1156/128513
> Received: 539
> Sent: 531
> Connections: 1
> Outstanding: 0
> Zxid: 0x10037
> Mode: follower
> Node count: 5
> 
> pguodeMacBook-Air:bin pguo$ echo cons | nc localhost 6181
>  
> /127.0.0.1:55759[1](queued=0,recved=5,sent=5,sid=0x157be2732de,lop=PING,est=1476372631116,to=15000,lcxid=0x1,lzxid=0x,lresp=1476372646260,llat=8,minlat=0,avglat=6,maxlat=17)
>  /0:0:0:0:0:0:0:1:55767[0](queued=0,recved=1,sent=0)
> 
> pguodeMacBook-Air:bin pguo$ echo wchp | nc localhost 6181
> /curator_exists_watch
>   0x357be48e4d90007
>   0x357be48e4d90009
>   0x157be2732de
> as above 4-letter's report shows, 0x357be48e4d90007 and 0x357be48e4d90009 
> are leaked after the two sessions expired 



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

FIY, I have found the message that alludes to the disabled comments: 
http://mail-archives.apache.org/mod_mbox/zookeeper-dev/201610.mbox/%3C3B936EF9-0695-45A9-AA65-8F7347AD0AC1%40apache.org%3E

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

[~breed], I left a couple of comments in the PR to guide us. Still grokking 
this script too.

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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

[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github

[Edward Ribeiro (JIRA)]

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

Edward Ribeiro commented on ZOOKEEPER-2597:
---

*AFAIK*, the bridge of GH review comments to JIRA is disabled (by default?). At 
least I remember someone linking a Kafka discussion about that...

> Add script to merge PR from Apache git repo to Github
> -
>
> Key: ZOOKEEPER-2597
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Edward Ribeiro
>Priority: Minor
> Attachments: ZOOKEEPER-2597.patch
>
>
> A port of kafka-merge-pr.py to workon on ZooKeeper repo.



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