[jira] [Commented] (ZOOKEEPER-2193) reconfig command completes even if parameter is wrong obviously

[Yasuhito Fukuda (JIRA)]

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

Yasuhito Fukuda commented on ZOOKEEPER-2193:


[~rgs] thanks for your review.
I posted new diff on the reviewboard.

> reconfig command completes even if parameter is wrong obviously
> ---
>
> Key: ZOOKEEPER-2193
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: leaderElection, server
>Affects Versions: 3.5.0
> Environment: CentOS7 + Java7
>Reporter: Yasuhito Fukuda
>Assignee: Yasuhito Fukuda
> Attachments: ZOOKEEPER-2193-v2.patch, ZOOKEEPER-2193-v3.patch, 
> ZOOKEEPER-2193.patch
>
>
> Even if reconfig parameter is wrong, it was confirmed to complete.
> refer to the following.
> - Ensemble consists of four nodes
> {noformat}
> [zk: vm-101:2181(CONNECTED) 0] config
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> version=1
> {noformat}
> - add node by reconfig command
> {noformat}
> [zk: vm-101:2181(CONNECTED) 9] reconfig -add 
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> Committed new configuration:
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> version=30007
> {noformat}
> server.4 and server.5 of the IP address is a duplicate.
> In this state, reader election will not work properly.
> Besides, it is assumed an ensemble will be undesirable state.
> I think that need a parameter validation when reconfig.



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

Re: Review Request 35204: ZOOKEEPER-2193: reconfig command completes even if parameter is wrong obviously

[Yasuhito Fukuda]

> On 6月 9, 2015, 10:12 a.m., Raul Gutierrez Segales wrote:
> > src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java, line 304
> > 
> >
> > sounds like myAddrs could be constructed and saved from the 
> > constructor, to avoid building it on every call, no?

Yes indeed!
myAddr will construct in the constructor.
at the same time, I modified constructor overloading in QuorumPeer class.


- Yasuhito


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


On 6月 9, 2015, 3:45 p.m., Yasuhito Fukuda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35204/
> ---
> 
> (Updated 6月 9, 2015, 3:45 p.m.)
> 
> 
> Review request for zookeeper.
> 
> 
> Bugs: ZOOKEEPER-2193
> https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> 
> 
> Repository: zookeeper-git
> 
> 
> Description
> ---
> 
> See ZOOKEEPER-2193
> 
> 
> Diffs
> -
> 
>   src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
> 73fa4e67a09806c90a6037d9a170179cb806b896 
>   src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java 
> f15f831701f9c8514db5003ebd550cd3880b48c7 
> 
> Diff: https://reviews.apache.org/r/35204/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yasuhito Fukuda
> 
>

Re: Review Request 35204: ZOOKEEPER-2193: reconfig command completes even if parameter is wrong obviously

[Yasuhito Fukuda]

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

(Updated 6月 9, 2015, 3:45 p.m.)


Review request for zookeeper.


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


Repository: zookeeper-git


Description
---

See ZOOKEEPER-2193


Diffs (updated)
-

  src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
73fa4e67a09806c90a6037d9a170179cb806b896 
  src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java 
f15f831701f9c8514db5003ebd550cd3880b48c7 

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


Testing
---


Thanks,

Yasuhito Fukuda

[jira] [Reopened] (ZOOKEEPER-2163) Introduce new ZNode type: container

[Michi Mutsuzaki (JIRA)]

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

Michi Mutsuzaki reopened ZOOKEEPER-2163:


[~rgs] could you address Rakesh's comment?

> Introduce new ZNode type: container
> ---
>
> Key: ZOOKEEPER-2163
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client, server
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.5.1, 3.6.0
>
> Attachments: zookeeper-2163.10.patch, zookeeper-2163.11.patch, 
> zookeeper-2163.12.patch, zookeeper-2163.13.patch, zookeeper-2163.14.patch, 
> zookeeper-2163.3.patch, zookeeper-2163.5.patch, zookeeper-2163.6.patch, 
> zookeeper-2163.7.patch, zookeeper-2163.8.patch, zookeeper-2163.9.patch
>
>
> BACKGROUND
> 
> A recurring problem for ZooKeeper users is garbage collection of parent 
> nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a 
> parent node under which participants create sequential nodes. When the 
> participant is done, it deletes its node. In practice, the ZooKeeper tree 
> begins to fill up with orphaned parent nodes that are no longer needed. The 
> ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can 
> become unstable due to the number of these nodes.
> CURRENT SOLUTIONS
> ===
> Apache Curator has a workaround solution for this by providing the Reaper 
> class which runs in the background looking for orphaned parent nodes and 
> deleting them. This isn’t ideal and it would be better if ZooKeeper supported 
> this directly.
> PROPOSAL
> =
> ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes 
> to contain child nodes. This is not optimum as EPHEMERALs are tied to a 
> session and the general use case of parent nodes is for PERSISTENT nodes. 
> This proposal adds a new node type, CONTAINER. A CONTAINER node is the same 
> as a PERSISTENT node with the additional property that when its last child is 
> deleted, it is deleted (and CONTAINER nodes recursively up the tree are 
> deleted if empty).
> CANONICAL USAGE
> 
> {code}
> while ( true) { // or some reasonable limit
> try {
> zk.create(path, ...);
> break;
> } catch ( KeeperException.NoNodeException e ) {
> try {
> zk.createContainer(containerPath, ...);
> } catch ( KeeperException.NodeExistsException ignore) {
>}
> }
> }
> {code}



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

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Michi Mutsuzaki]

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

I'm cancelling the vote to address this issue.

On Mon, Jun 8, 2015 at 9:25 PM, Michi Mutsuzaki  wrote:
> Thanks Raul for reporting. I'll take a look.
>
> On Mon, Jun 8, 2015 at 5:12 PM, Raúl Gutiérrez Segalés
>  wrote:
>> I can't confirm this since I don't have OS X, but I think the C library is
>> broken there because of this change:
>>
>> https://github.com/apache/zookeeper/commit/41c9fcb3ca09cd3d05e59fe47f08ecf0b85532c8
>>
>> (got some reports on #zookeeper today, not sure if that's a showstopper for
>> the RC - probably it is).
>>
>>
>> -rgs
>>
>> On 8 June 2015 at 01:37, Michi Mutsuzaki  wrote:
>>
>>> This is the third release candidate for 3.5.1-alpha. The full release
>>> notes is available at:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>>>
>>> *** Please download, test and vote by June 26th 2015, 23:59 UTC+0. ***
>>>
>>> Source files:
>>> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-2/
>>>
>>> Maven staging repo:
>>>
>>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>>>
>>> The tag to be voted upon:
>>> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc2/
>>>
>>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>>> http://www.apache.org/dist/zookeeper/KEYS
>>>
>>> Should we release this candidate?
>>>

[jira] [Created] (ZOOKEEPER-2210) clock_gettime is not available in os x

[Michi Mutsuzaki (JIRA)]

Michi Mutsuzaki created ZOOKEEPER-2210:
--

 Summary: clock_gettime is not available in os x
 Key: ZOOKEEPER-2210
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2210
 Project: ZooKeeper
  Issue Type: Bug
  Components: c client
Reporter: Michi Mutsuzaki
Assignee: Michi Mutsuzaki
 Fix For: 3.5.1, 3.6.0


{noformat}
src/zookeeper.c:286:9: warning: implicit declaration of function 
'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
  ret = clock_gettime(CLOCK_MONOTONIC, &ts);
^
src/zookeeper.c:286:23: error: use of undeclared identifier 'CLOCK_MONOTONIC'
  ret = clock_gettime(CLOCK_MONOTONIC, &ts);
{noformat}



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

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Michi Mutsuzaki]

Thanks Raul for reporting. I'll take a look.

On Mon, Jun 8, 2015 at 5:12 PM, Raúl Gutiérrez Segalés
 wrote:
> I can't confirm this since I don't have OS X, but I think the C library is
> broken there because of this change:
>
> https://github.com/apache/zookeeper/commit/41c9fcb3ca09cd3d05e59fe47f08ecf0b85532c8
>
> (got some reports on #zookeeper today, not sure if that's a showstopper for
> the RC - probably it is).
>
>
> -rgs
>
> On 8 June 2015 at 01:37, Michi Mutsuzaki  wrote:
>
>> This is the third release candidate for 3.5.1-alpha. The full release
>> notes is available at:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>>
>> *** Please download, test and vote by June 26th 2015, 23:59 UTC+0. ***
>>
>> Source files:
>> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-2/
>>
>> Maven staging repo:
>>
>> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>>
>> The tag to be voted upon:
>> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc2/
>>
>> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
>> http://www.apache.org/dist/zookeeper/KEYS
>>
>> Should we release this candidate?
>>

Re: do we need a corresponding JIRA for each (github) PR?

[Michi Mutsuzaki]

We could also set up automated builds on pull requests.

https://blogs.apache.org/infra/entry/github_pull_request_builds_now

Also, I found this discussion regrading accepting github pull requests.

https://issues.apache.org/jira/browse/LEGAL-156


On Mon, Jun 8, 2015 at 11:39 AM, Raúl Gutiérrez Segalés
 wrote:
> On 8 June 2015 at 11:21, Raúl Gutiérrez Segalés  wrote:
>
>> On 8 June 2015 at 11:13, Patrick Hunt  wrote:
>>
>>> Sounds reasonable. I have reached out personally in the past, but
>>> having it be automated would be good. Perhaps you can discuss with the
>>> apache infra team as to what is possible?
>>>
>>
>> Yeah, I'll ping them and get back to this thread with what's possible.
>>
>
> Filed
> https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9788 to
> get the pull
> request auto-responder going (
> https://github.com/blog/144-pull-request-auto-responder).
>
>
>
> -rgs

[jira] [Commented] (ZOOKEEPER-2193) reconfig command completes even if parameter is wrong obviously

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales commented on ZOOKEEPER-2193:
---

Thanks for the patch [~Yasuhito Fukuda], commented on a few issues/nits on the 
reviewboard. 

> reconfig command completes even if parameter is wrong obviously
> ---
>
> Key: ZOOKEEPER-2193
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: leaderElection, server
>Affects Versions: 3.5.0
> Environment: CentOS7 + Java7
>Reporter: Yasuhito Fukuda
>Assignee: Yasuhito Fukuda
> Attachments: ZOOKEEPER-2193-v2.patch, ZOOKEEPER-2193-v3.patch, 
> ZOOKEEPER-2193.patch
>
>
> Even if reconfig parameter is wrong, it was confirmed to complete.
> refer to the following.
> - Ensemble consists of four nodes
> {noformat}
> [zk: vm-101:2181(CONNECTED) 0] config
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> version=1
> {noformat}
> - add node by reconfig command
> {noformat}
> [zk: vm-101:2181(CONNECTED) 9] reconfig -add 
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> Committed new configuration:
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> version=30007
> {noformat}
> server.4 and server.5 of the IP address is a duplicate.
> In this state, reader election will not work properly.
> Besides, it is assumed an ensemble will be undesirable state.
> I think that need a parameter validation when reconfig.



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

Re: Review Request 35204: ZOOKEEPER-2193: reconfig command completes even if parameter is wrong obviously

[Raul Gutierrez Segales]

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



src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java


remove the extra whitespaces/tabs (i.e.: the red part in the RB).



src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java


sounds like myAddrs could be constructed and saved from the constructor, to 
avoid building it on every call, no?



src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java


typo, excludedSpecialAddress



src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java


whitespace/tabs


- Raul Gutierrez Segales


On June 8, 2015, 9:44 a.m., Yasuhito Fukuda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35204/
> ---
> 
> (Updated June 8, 2015, 9:44 a.m.)
> 
> 
> Review request for zookeeper.
> 
> 
> Bugs: ZOOKEEPER-2193
> https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> 
> 
> Repository: zookeeper-git
> 
> 
> Description
> ---
> 
> See ZOOKEEPER-2193
> 
> 
> Diffs
> -
> 
>   src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
> 73fa4e67a09806c90a6037d9a170179cb806b896 
>   src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java 
> f15f831701f9c8514db5003ebd550cd3880b48c7 
> 
> Diff: https://reviews.apache.org/r/35204/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Yasuhito Fukuda
> 
>

Re: [VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Raúl Gutiérrez Segalés]

I can't confirm this since I don't have OS X, but I think the C library is
broken there because of this change:

https://github.com/apache/zookeeper/commit/41c9fcb3ca09cd3d05e59fe47f08ecf0b85532c8

(got some reports on #zookeeper today, not sure if that's a showstopper for
the RC - probably it is).


-rgs

On 8 June 2015 at 01:37, Michi Mutsuzaki  wrote:

> This is the third release candidate for 3.5.1-alpha. The full release
> notes is available at:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786
>
> *** Please download, test and vote by June 26th 2015, 23:59 UTC+0. ***
>
> Source files:
> http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-2/
>
> Maven staging repo:
>
> https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/
>
> The tag to be voted upon:
> https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc2/
>
> ZooKeeper's KEYS file containing PGP keys we use to sign the release:
> http://www.apache.org/dist/zookeeper/KEYS
>
> Should we release this candidate?
>

[jira] [Commented] (ZOOKEEPER-2168) Add C APIs for new createContainer Methods

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales commented on ZOOKEEPER-2168:
---

*pull request

> Add C APIs for new createContainer Methods
> --
>
> Key: ZOOKEEPER-2168
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>
> ZOOKEEPER-2163 adds new client methods to create containers. These need to be 
> exposed in the C client as well.



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

[jira] [Commented] (ZOOKEEPER-2168) Add C APIs for new createContainer Methods

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales commented on ZOOKEEPER-2168:
---

Commented on the pull requests. Can we have a test or two too? Thanks!

> Add C APIs for new createContainer Methods
> --
>
> Key: ZOOKEEPER-2168
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>
> ZOOKEEPER-2163 adds new client methods to create containers. These need to be 
> exposed in the C client as well.



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

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 11:21, Raúl Gutiérrez Segalés  wrote:

> On 8 June 2015 at 11:13, Patrick Hunt  wrote:
>
>> Sounds reasonable. I have reached out personally in the past, but
>> having it be automated would be good. Perhaps you can discuss with the
>> apache infra team as to what is possible?
>>
>
> Yeah, I'll ping them and get back to this thread with what's possible.
>

Filed
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9788 to
get the pull
request auto-responder going (
https://github.com/blog/144-pull-request-auto-responder).



-rgs

[jira] [Commented] (ZOOKEEPER-2186) QuorumCnxManager#receiveConnection may crash with random input

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ZOOKEEPER-2186:
---

Github user rgs1 closed the pull request at:

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


> QuorumCnxManager#receiveConnection may crash with random input
> --
>
> Key: ZOOKEEPER-2186
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2186
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6, 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
> Fix For: 3.4.7, 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2186-v3.4.patch, ZOOKEEPER-2186.patch, 
> ZOOKEEPER-2186.patch, ZOOKEEPER-2186.patch
>
>
> This will allocate an arbitrarily large byte buffer (and try to read it!):
> {code}
> public boolean receiveConnection(Socket sock) {
> Long sid = null;
> ...
> sid = din.readLong();
> // next comes the #bytes in the remainder of the message  
>
> int num_remaining_bytes = din.readInt();
> byte[] b = new byte[num_remaining_bytes];
> // remove the remainder of the message from din   
>
> int num_read = din.read(b);
> {code}
> This will crash the QuorumCnxManager thread, so the cluster will keep going 
> but future elections might fail to converge (ditto for leaving/joining 
> members). 
> Patch coming up in a bit.



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

[GitHub] zookeeper pull request: ZOOKEEPER-2186: QuorumCnxManager#receiveCo...

[rgs1]

Github user rgs1 closed the pull request at:

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


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

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 11:13, Patrick Hunt  wrote:

> Sounds reasonable. I have reached out personally in the past, but
> having it be automated would be good. Perhaps you can discuss with the
> apache infra team as to what is possible?
>

Yeah, I'll ping them and get back to this thread with what's possible.


-rgs




>
> Patrick
>
> On Mon, Jun 8, 2015 at 10:40 AM, Raúl Gutiérrez Segalés
>  wrote:
> > One final note for posterity and people interested in using PRs for the
> > review process
> > at least (which I guess is ok) is that the ASF GitHub Bot will actually
> > ping the associated
> > JIRA if you reference it from your PR, i.e.;
> >
> > https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> > https://github.com/apache/zookeeper/pull/33
> >
> > I guess it would be nice if the Bot also commented on PRs pointing out
> > to the `How to Contribute` link or simply saying that you need to create
> a
> > JIRA and
> > then you can reference it from your PR.
> >
> >
> > -rgs
> >
> > On 8 June 2015 at 10:09, Raúl Gutiérrez Segalés 
> wrote:
> >
> >> On 8 June 2015 at 10:07, Patrick Hunt  wrote:
> >>
> >>> Keep in mind that filing the jira, attaching the patch file, etc...
> >>> are all demonstrating intent of the author to contribute the changes
> >>> under the apache license conditions. Jira is part of IP tracking. If
> >>> you file the jira for them we lose that. We used to (olden days) have
> >>> a specific checkbox in jira that required the patch author to
> >>> explicitly specify intent, but at some point that was dropped.
> >>>
> >>> So don't file the jira for someone else. Let them create the jira,
> >>> attach the patch, etc... - regardless they are going to need to
> >>> interact with jira in order to work through the feedback, discussions,
> >>> etc...
> >>>
> >>
> >> Cool. Thanks Pat, Camille and Chris!
> >>
> >>
> >> -rgs
> >>
> >>
>

Re: do we need a corresponding JIRA for each (github) PR?

[Patrick Hunt]

Sounds reasonable. I have reached out personally in the past, but
having it be automated would be good. Perhaps you can discuss with the
apache infra team as to what is possible?

Patrick

On Mon, Jun 8, 2015 at 10:40 AM, Raúl Gutiérrez Segalés
 wrote:
> One final note for posterity and people interested in using PRs for the
> review process
> at least (which I guess is ok) is that the ASF GitHub Bot will actually
> ping the associated
> JIRA if you reference it from your PR, i.e.;
>
> https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> https://github.com/apache/zookeeper/pull/33
>
> I guess it would be nice if the Bot also commented on PRs pointing out
> to the `How to Contribute` link or simply saying that you need to create a
> JIRA and
> then you can reference it from your PR.
>
>
> -rgs
>
> On 8 June 2015 at 10:09, Raúl Gutiérrez Segalés  wrote:
>
>> On 8 June 2015 at 10:07, Patrick Hunt  wrote:
>>
>>> Keep in mind that filing the jira, attaching the patch file, etc...
>>> are all demonstrating intent of the author to contribute the changes
>>> under the apache license conditions. Jira is part of IP tracking. If
>>> you file the jira for them we lose that. We used to (olden days) have
>>> a specific checkbox in jira that required the patch author to
>>> explicitly specify intent, but at some point that was dropped.
>>>
>>> So don't file the jira for someone else. Let them create the jira,
>>> attach the patch, etc... - regardless they are going to need to
>>> interact with jira in order to work through the feedback, discussions,
>>> etc...
>>>
>>
>> Cool. Thanks Pat, Camille and Chris!
>>
>>
>> -rgs
>>
>>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

One final note for posterity and people interested in using PRs for the
review process
at least (which I guess is ok) is that the ASF GitHub Bot will actually
ping the associated
JIRA if you reference it from your PR, i.e.;

https://issues.apache.org/jira/browse/ZOOKEEPER-2168
https://github.com/apache/zookeeper/pull/33

I guess it would be nice if the Bot also commented on PRs pointing out
to the `How to Contribute` link or simply saying that you need to create a
JIRA and
then you can reference it from your PR.


-rgs

On 8 June 2015 at 10:09, Raúl Gutiérrez Segalés  wrote:

> On 8 June 2015 at 10:07, Patrick Hunt  wrote:
>
>> Keep in mind that filing the jira, attaching the patch file, etc...
>> are all demonstrating intent of the author to contribute the changes
>> under the apache license conditions. Jira is part of IP tracking. If
>> you file the jira for them we lose that. We used to (olden days) have
>> a specific checkbox in jira that required the patch author to
>> explicitly specify intent, but at some point that was dropped.
>>
>> So don't file the jira for someone else. Let them create the jira,
>> attach the patch, etc... - regardless they are going to need to
>> interact with jira in order to work through the feedback, discussions,
>> etc...
>>
>
> Cool. Thanks Pat, Camille and Chris!
>
>
> -rgs
>
>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

On 8 June 2015 at 10:07, Patrick Hunt  wrote:

> Keep in mind that filing the jira, attaching the patch file, etc...
> are all demonstrating intent of the author to contribute the changes
> under the apache license conditions. Jira is part of IP tracking. If
> you file the jira for them we lose that. We used to (olden days) have
> a specific checkbox in jira that required the patch author to
> explicitly specify intent, but at some point that was dropped.
>
> So don't file the jira for someone else. Let them create the jira,
> attach the patch, etc... - regardless they are going to need to
> interact with jira in order to work through the feedback, discussions,
> etc...
>

Cool. Thanks Pat, Camille and Chris!


-rgs

Re: do we need a corresponding JIRA for each (github) PR?

[Patrick Hunt]

Keep in mind that filing the jira, attaching the patch file, etc...
are all demonstrating intent of the author to contribute the changes
under the apache license conditions. Jira is part of IP tracking. If
you file the jira for them we lose that. We used to (olden days) have
a specific checkbox in jira that required the patch author to
explicitly specify intent, but at some point that was dropped.

So don't file the jira for someone else. Let them create the jira,
attach the patch, etc... - regardless they are going to need to
interact with jira in order to work through the feedback, discussions,
etc...

Patrick

On Mon, Jun 8, 2015 at 9:59 AM, Raúl Gutiérrez Segalés
 wrote:
> Fair enough. I do agree that multiple sources of truth is not great (even
> if avoiding it means some copy/pasta
> between PRs and JIRAs).
>
> For now, I guess we can just ask people to open JIRAs, or file them for the
> casual contributors.
>
> Thanks all!
>
>
> -rgs
>
>
>
> On 8 June 2015 at 09:27, Patrick Hunt  wrote:
>
>> Agree with the single record of truth. All changes currently go
>> through Jira. It's part of the process and documented in the "how to
>> contribute" page:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
>>
>> The git mirror at github is just that, a mirror of svn and meant to be
>> a convenience. We don't use the PR process there, etc...
>>
>> Patrick
>>
>> On Mon, Jun 8, 2015 at 9:06 AM, Chris Nauroth 
>> wrote:
>> > FWIW, the JIRA requirement is typical of Apache projects.  Most projects
>> > have a strong preference that this single record of truth lies on Apache
>> > infrastructure, hence the use of Apache JIRA and Apache's hosted git
>> > rather than GitHub.  The idea is that a full permanent record of all
>> > project decisions resides in Apache infrastructure, maintained by the
>> ASF,
>> > and not subject to external forces like a company folding and needing to
>> > shut down its site.  (I don't have any reason to suspect this of GitHub,
>> > but the point is that it's something outside of ASF control.)
>> >
>> > I don't know for sure that this is a required policy, but I wanted to
>> > point out that it's consistent with the Apache projects I've seen.
>> >
>> > --Chris Nauroth
>> >
>> >
>> >
>> >
>> > On 6/8/15, 5:19 AM, "Camille Fournier"  wrote:
>> >
>> >>I personally don't think that having a single record of truth and asking
>> >>people to use that record is asking too much. I'm not in favor at all of
>> >>removing the requirement for tickets to track work. Perhaps if we were
>> >>entirely in git hub it would be one thing but we aren't.
>> >>
>> >>C
>> >>On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
>> >>wrote:
>> >>
>> >>> Hi Camille,
>> >>>
>> >>> On 7 June 2015 at 14:59, Camille Fournier  wrote:
>> >>>
>> >>> > I personally think all PRs should have an associated JIRA. This is
>> >>>also
>> >>> the
>> >>> > requirement I have on my engineering team at work, and it seems
>> >>>totally
>> >>> > reasonable to me.
>> >>> >
>> >>>
>> >>> Thanks for sharing! Is it with a git pull request work flow though?
>> Take
>> >>> this ‹ small albeit important ‹
>> >>> pull request for instance:
>> >>>
>> >>> https://github.com/apache/zookeeper/pull/32
>> >>>
>> >>> I think it would be nice to avoid asking casual contributors to file
>> >>>JIRAs
>> >>> for those small patches so
>> >>> the impedance for contributing is reduced.
>> >>>
>> >>> Also, having the committer do the paperwork sounds like too much red
>> >>>tape
>> >>> given that
>> >>> the pull request is already pretty well documented. I at least would be
>> >>> very happy
>> >>> if we could just push those patches by referencing the PR in the
>> >>>comment,
>> >>> instead of a JIRA.
>> >>>
>> >>> I also suspect that eventually we might end up moving to git, so I
>> think
>> >>> there is value in allowing
>> >>> pull requests as a submission mechanism (for some cases?), since it'll
>> >>>make
>> >>> the eventual transition
>> >>> smoother and with less unknowns.
>> >>>
>> >>>
>> >>> -rgs
>> >>>
>> >>>
>> >>>
>> >>> > C
>> >>> >
>> >>> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
>> >>> > r...@itevenworks.net>
>> >>> > wrote:
>> >>> >
>> >>> > > Heya,
>> >>> > >
>> >>> > > there's an increasing number of pull requests (PRs) coming through
>> >>> github
>> >>> > > (great! more contributions!). How do we deal with them? Do we need
>> >>>to
>> >>> > file
>> >>> > > a corresponding JIRA before we merge them or can we just reference
>> >>>the
>> >>> > PR?
>> >>> > >
>> >>> > > I rather not tax the contributors with having to file the JIRA, but
>> >>> > taxing
>> >>> > > the committer is also not great.. Thoughts?
>> >>> > >
>> >>> > >
>> >>> > > -rgs
>> >>> > >
>> >>> >
>> >>>
>> >
>>

Re: do we need a corresponding JIRA for each (github) PR?

[Raúl Gutiérrez Segalés]

Fair enough. I do agree that multiple sources of truth is not great (even
if avoiding it means some copy/pasta
between PRs and JIRAs).

For now, I guess we can just ask people to open JIRAs, or file them for the
casual contributors.

Thanks all!


-rgs



On 8 June 2015 at 09:27, Patrick Hunt  wrote:

> Agree with the single record of truth. All changes currently go
> through Jira. It's part of the process and documented in the "how to
> contribute" page:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
>
> The git mirror at github is just that, a mirror of svn and meant to be
> a convenience. We don't use the PR process there, etc...
>
> Patrick
>
> On Mon, Jun 8, 2015 at 9:06 AM, Chris Nauroth 
> wrote:
> > FWIW, the JIRA requirement is typical of Apache projects.  Most projects
> > have a strong preference that this single record of truth lies on Apache
> > infrastructure, hence the use of Apache JIRA and Apache's hosted git
> > rather than GitHub.  The idea is that a full permanent record of all
> > project decisions resides in Apache infrastructure, maintained by the
> ASF,
> > and not subject to external forces like a company folding and needing to
> > shut down its site.  (I don't have any reason to suspect this of GitHub,
> > but the point is that it's something outside of ASF control.)
> >
> > I don't know for sure that this is a required policy, but I wanted to
> > point out that it's consistent with the Apache projects I've seen.
> >
> > --Chris Nauroth
> >
> >
> >
> >
> > On 6/8/15, 5:19 AM, "Camille Fournier"  wrote:
> >
> >>I personally don't think that having a single record of truth and asking
> >>people to use that record is asking too much. I'm not in favor at all of
> >>removing the requirement for tickets to track work. Perhaps if we were
> >>entirely in git hub it would be one thing but we aren't.
> >>
> >>C
> >>On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
> >>wrote:
> >>
> >>> Hi Camille,
> >>>
> >>> On 7 June 2015 at 14:59, Camille Fournier  wrote:
> >>>
> >>> > I personally think all PRs should have an associated JIRA. This is
> >>>also
> >>> the
> >>> > requirement I have on my engineering team at work, and it seems
> >>>totally
> >>> > reasonable to me.
> >>> >
> >>>
> >>> Thanks for sharing! Is it with a git pull request work flow though?
> Take
> >>> this ‹ small albeit important ‹
> >>> pull request for instance:
> >>>
> >>> https://github.com/apache/zookeeper/pull/32
> >>>
> >>> I think it would be nice to avoid asking casual contributors to file
> >>>JIRAs
> >>> for those small patches so
> >>> the impedance for contributing is reduced.
> >>>
> >>> Also, having the committer do the paperwork sounds like too much red
> >>>tape
> >>> given that
> >>> the pull request is already pretty well documented. I at least would be
> >>> very happy
> >>> if we could just push those patches by referencing the PR in the
> >>>comment,
> >>> instead of a JIRA.
> >>>
> >>> I also suspect that eventually we might end up moving to git, so I
> think
> >>> there is value in allowing
> >>> pull requests as a submission mechanism (for some cases?), since it'll
> >>>make
> >>> the eventual transition
> >>> smoother and with less unknowns.
> >>>
> >>>
> >>> -rgs
> >>>
> >>>
> >>>
> >>> > C
> >>> >
> >>> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
> >>> > r...@itevenworks.net>
> >>> > wrote:
> >>> >
> >>> > > Heya,
> >>> > >
> >>> > > there's an increasing number of pull requests (PRs) coming through
> >>> github
> >>> > > (great! more contributions!). How do we deal with them? Do we need
> >>>to
> >>> > file
> >>> > > a corresponding JIRA before we merge them or can we just reference
> >>>the
> >>> > PR?
> >>> > >
> >>> > > I rather not tax the contributors with having to file the JIRA, but
> >>> > taxing
> >>> > > the committer is also not great.. Thoughts?
> >>> > >
> >>> > >
> >>> > > -rgs
> >>> > >
> >>> >
> >>>
> >
>

Re: do we need a corresponding JIRA for each (github) PR?

[Patrick Hunt]

Agree with the single record of truth. All changes currently go
through Jira. It's part of the process and documented in the "how to
contribute" page:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute

The git mirror at github is just that, a mirror of svn and meant to be
a convenience. We don't use the PR process there, etc...

Patrick

On Mon, Jun 8, 2015 at 9:06 AM, Chris Nauroth  wrote:
> FWIW, the JIRA requirement is typical of Apache projects.  Most projects
> have a strong preference that this single record of truth lies on Apache
> infrastructure, hence the use of Apache JIRA and Apache's hosted git
> rather than GitHub.  The idea is that a full permanent record of all
> project decisions resides in Apache infrastructure, maintained by the ASF,
> and not subject to external forces like a company folding and needing to
> shut down its site.  (I don't have any reason to suspect this of GitHub,
> but the point is that it's something outside of ASF control.)
>
> I don't know for sure that this is a required policy, but I wanted to
> point out that it's consistent with the Apache projects I've seen.
>
> --Chris Nauroth
>
>
>
>
> On 6/8/15, 5:19 AM, "Camille Fournier"  wrote:
>
>>I personally don't think that having a single record of truth and asking
>>people to use that record is asking too much. I'm not in favor at all of
>>removing the requirement for tickets to track work. Perhaps if we were
>>entirely in git hub it would be one thing but we aren't.
>>
>>C
>>On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
>>wrote:
>>
>>> Hi Camille,
>>>
>>> On 7 June 2015 at 14:59, Camille Fournier  wrote:
>>>
>>> > I personally think all PRs should have an associated JIRA. This is
>>>also
>>> the
>>> > requirement I have on my engineering team at work, and it seems
>>>totally
>>> > reasonable to me.
>>> >
>>>
>>> Thanks for sharing! Is it with a git pull request work flow though? Take
>>> this ‹ small albeit important ‹
>>> pull request for instance:
>>>
>>> https://github.com/apache/zookeeper/pull/32
>>>
>>> I think it would be nice to avoid asking casual contributors to file
>>>JIRAs
>>> for those small patches so
>>> the impedance for contributing is reduced.
>>>
>>> Also, having the committer do the paperwork sounds like too much red
>>>tape
>>> given that
>>> the pull request is already pretty well documented. I at least would be
>>> very happy
>>> if we could just push those patches by referencing the PR in the
>>>comment,
>>> instead of a JIRA.
>>>
>>> I also suspect that eventually we might end up moving to git, so I think
>>> there is value in allowing
>>> pull requests as a submission mechanism (for some cases?), since it'll
>>>make
>>> the eventual transition
>>> smoother and with less unknowns.
>>>
>>>
>>> -rgs
>>>
>>>
>>>
>>> > C
>>> >
>>> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
>>> > r...@itevenworks.net>
>>> > wrote:
>>> >
>>> > > Heya,
>>> > >
>>> > > there's an increasing number of pull requests (PRs) coming through
>>> github
>>> > > (great! more contributions!). How do we deal with them? Do we need
>>>to
>>> > file
>>> > > a corresponding JIRA before we merge them or can we just reference
>>>the
>>> > PR?
>>> > >
>>> > > I rather not tax the contributors with having to file the JIRA, but
>>> > taxing
>>> > > the committer is also not great.. Thoughts?
>>> > >
>>> > >
>>> > > -rgs
>>> > >
>>> >
>>>
>

Re: do we need a corresponding JIRA for each (github) PR?

[Chris Nauroth]

FWIW, the JIRA requirement is typical of Apache projects.  Most projects
have a strong preference that this single record of truth lies on Apache
infrastructure, hence the use of Apache JIRA and Apache's hosted git
rather than GitHub.  The idea is that a full permanent record of all
project decisions resides in Apache infrastructure, maintained by the ASF,
and not subject to external forces like a company folding and needing to
shut down its site.  (I don't have any reason to suspect this of GitHub,
but the point is that it's something outside of ASF control.)

I don't know for sure that this is a required policy, but I wanted to
point out that it's consistent with the Apache projects I've seen.

--Chris Nauroth




On 6/8/15, 5:19 AM, "Camille Fournier"  wrote:

>I personally don't think that having a single record of truth and asking
>people to use that record is asking too much. I'm not in favor at all of
>removing the requirement for tickets to track work. Perhaps if we were
>entirely in git hub it would be one thing but we aren't.
>
>C
>On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
>wrote:
>
>> Hi Camille,
>>
>> On 7 June 2015 at 14:59, Camille Fournier  wrote:
>>
>> > I personally think all PRs should have an associated JIRA. This is
>>also
>> the
>> > requirement I have on my engineering team at work, and it seems
>>totally
>> > reasonable to me.
>> >
>>
>> Thanks for sharing! Is it with a git pull request work flow though? Take
>> this ‹ small albeit important ‹
>> pull request for instance:
>>
>> https://github.com/apache/zookeeper/pull/32
>>
>> I think it would be nice to avoid asking casual contributors to file
>>JIRAs
>> for those small patches so
>> the impedance for contributing is reduced.
>>
>> Also, having the committer do the paperwork sounds like too much red
>>tape
>> given that
>> the pull request is already pretty well documented. I at least would be
>> very happy
>> if we could just push those patches by referencing the PR in the
>>comment,
>> instead of a JIRA.
>>
>> I also suspect that eventually we might end up moving to git, so I think
>> there is value in allowing
>> pull requests as a submission mechanism (for some cases?), since it'll
>>make
>> the eventual transition
>> smoother and with less unknowns.
>>
>>
>> -rgs
>>
>>
>>
>> > C
>> >
>> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
>> > r...@itevenworks.net>
>> > wrote:
>> >
>> > > Heya,
>> > >
>> > > there's an increasing number of pull requests (PRs) coming through
>> github
>> > > (great! more contributions!). How do we deal with them? Do we need
>>to
>> > file
>> > > a corresponding JIRA before we merge them or can we just reference
>>the
>> > PR?
>> > >
>> > > I rather not tax the contributors with having to file the JIRA, but
>> > taxing
>> > > the committer is also not great.. Thoughts?
>> > >
>> > >
>> > > -rgs
>> > >
>> >
>>

[GitHub] zookeeper pull request: ZOOKEEPER-2168 - first pass at C changes f...

[Randgalt]

GitHub user Randgalt opened a pull request:

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

ZOOKEEPER-2168 - first pass at C changes for containers

The C build doesn't compile on my Mac and it's been ages since I wrote any 
C. So, this needs careful review.

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

$ git pull https://github.com/Randgalt/zookeeper ZOOKEEPER-2168

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

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

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

This closes #33


commit 9e295bb83be23deafcafc5a87e2cc0a6c3196daa
Author: randgalt 
Date:   2015-06-08T15:31:38Z

ZOOKEEPER-2168 - first pass at C changes for containers




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

[jira] [Commented] (ZOOKEEPER-2168) Add C APIs for new createContainer Methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ZOOKEEPER-2168:
---

GitHub user Randgalt opened a pull request:

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

ZOOKEEPER-2168 - first pass at C changes for containers

The C build doesn't compile on my Mac and it's been ages since I wrote any 
C. So, this needs careful review.

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

$ git pull https://github.com/Randgalt/zookeeper ZOOKEEPER-2168

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

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

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

This closes #33


commit 9e295bb83be23deafcafc5a87e2cc0a6c3196daa
Author: randgalt 
Date:   2015-06-08T15:31:38Z

ZOOKEEPER-2168 - first pass at C changes for containers




> Add C APIs for new createContainer Methods
> --
>
> Key: ZOOKEEPER-2168
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2168
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>
> ZOOKEEPER-2163 adds new client methods to create containers. These need to be 
> exposed in the C client as well.



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

Re: do we need a corresponding JIRA for each (github) PR?

[Camille Fournier]

I personally don't think that having a single record of truth and asking
people to use that record is asking too much. I'm not in favor at all of
removing the requirement for tickets to track work. Perhaps if we were
entirely in git hub it would be one thing but we aren't.

C
On Jun 8, 2015 12:42 AM, "Raúl Gutiérrez Segalés" 
wrote:

> Hi Camille,
>
> On 7 June 2015 at 14:59, Camille Fournier  wrote:
>
> > I personally think all PRs should have an associated JIRA. This is also
> the
> > requirement I have on my engineering team at work, and it seems totally
> > reasonable to me.
> >
>
> Thanks for sharing! Is it with a git pull request work flow though? Take
> this — small albeit important —
> pull request for instance:
>
> https://github.com/apache/zookeeper/pull/32
>
> I think it would be nice to avoid asking casual contributors to file JIRAs
> for those small patches so
> the impedance for contributing is reduced.
>
> Also, having the committer do the paperwork sounds like too much red tape
> given that
> the pull request is already pretty well documented. I at least would be
> very happy
> if we could just push those patches by referencing the PR in the comment,
> instead of a JIRA.
>
> I also suspect that eventually we might end up moving to git, so I think
> there is value in allowing
> pull requests as a submission mechanism (for some cases?), since it'll make
> the eventual transition
> smoother and with less unknowns.
>
>
> -rgs
>
>
>
> > C
> >
> > On Sun, Jun 7, 2015 at 2:24 PM, Raúl Gutiérrez Segalés <
> > r...@itevenworks.net>
> > wrote:
> >
> > > Heya,
> > >
> > > there's an increasing number of pull requests (PRs) coming through
> github
> > > (great! more contributions!). How do we deal with them? Do we need to
> > file
> > > a corresponding JIRA before we merge them or can we just reference the
> > PR?
> > >
> > > I rather not tax the contributors with having to file the JIRA, but
> > taxing
> > > the committer is also not great.. Thoughts?
> > >
> > >
> > > -rgs
> > >
> >
>

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

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 374157 lines...]
[junit] 2015-06-08 11:06:40,831 [myid:] - INFO  
[main:FourLetterWordMain@63] - connecting to 127.0.0.1 11222
[junit] 2015-06-08 11:06:40,831 [myid:] - INFO  [main:JMXEnv@142] - 
ensureOnly:[]
[junit] 2015-06-08 11:06:40,833 [myid:] - INFO  [main:ClientBase@461] - 
STARTING server
[junit] 2015-06-08 11:06:40,833 [myid:] - INFO  [main:ClientBase@381] - 
CREATING server instance 127.0.0.1:11222
[junit] 2015-06-08 11:06:40,833 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 32 worker threads, and 64 
kB direct buffers.
[junit] 2015-06-08 11:06:40,834 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2015-06-08 11:06:40,835 [myid:] - INFO  [main:ClientBase@356] - 
STARTING server instance 127.0.0.1:11222
[junit] 2015-06-08 11:06:40,835 [myid:] - INFO  [main:ZooKeeperServer@825] 
- minSessionTimeout set to 6000
[junit] 2015-06-08 11:06:40,835 [myid:] - INFO  [main:ZooKeeperServer@834] 
- maxSessionTimeout set to 6
[junit] 2015-06-08 11:06:40,836 [myid:] - INFO  [main:ZooKeeperServer@156] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test7732062184609917455.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test7732062184609917455.junit.dir/version-2
[junit] 2015-06-08 11:06:40,837 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test7732062184609917455.junit.dir/version-2/snapshot.b
[junit] 2015-06-08 11:06:40,840 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk8/trunk/build/test/tmp/test7732062184609917455.junit.dir/version-2/snapshot.b
[junit] 2015-06-08 11:06:40,841 [myid:] - INFO  
[main:FourLetterWordMain@63] - connecting to 127.0.0.1 11222
[junit] 2015-06-08 11:06:40,842 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:46842
[junit] 2015-06-08 11:06:40,843 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@836] - Processing stat command from 
/127.0.0.1:46842
[junit] 2015-06-08 11:06:40,843 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@685] - Stat command output
[junit] 2015-06-08 11:06:40,843 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@1007] - Closed socket connection for client 
/127.0.0.1:46842 (no session established for client)
[junit] 2015-06-08 11:06:40,844 [myid:] - INFO  [main:JMXEnv@224] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2015-06-08 11:06:40,845 [myid:] - INFO  [main:JMXEnv@241] - 
expect:InMemoryDataTree
[junit] 2015-06-08 11:06:40,845 [myid:] - INFO  [main:JMXEnv@245] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2015-06-08 11:06:40,845 [myid:] - INFO  [main:JMXEnv@241] - 
expect:StandaloneServer_port
[junit] 2015-06-08 11:06:40,845 [myid:] - INFO  [main:JMXEnv@245] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2015-06-08 11:06:40,846 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 62100
[junit] 2015-06-08 11:06:40,846 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 24
[junit] 2015-06-08 11:06:40,846 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2015-06-08 11:06:40,846 [myid:] - INFO  [main:ClientBase@538] - 
tearDown starting
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  [main:ZooKeeper@1110] - 
Session: 0x101017e2d38 closed
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  [main:ClientBase@508] - 
STOPPING server
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@531] - EventThread shut down for 
session: 0x101017e2d38
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2015-06-08 11:06:40,906 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFacto

ZooKeeper-trunk - Build # 2720 - Failure

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 372771 lines...]
 [exec] Log Message Received: [2015-06-08 
10:46:32,908:6326(0x2ab909b51540):ZOO_INFO@log_env@1013: Client 
environment:user.name=jenkins]
 [exec] Log Message Received: [2015-06-08 
10:46:32,908:6326(0x2ab909b51540):ZOO_INFO@log_env@1021: Client 
environment:user.home=/home/jenkins]
 [exec] Log Message Received: [2015-06-08 
10:46:32,908:6326(0x2ab909b51540):ZOO_INFO@log_env@1033: Client 
environment:user.dir=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit]
 [exec] Log Message Received: [2015-06-08 
10:46:32,908:6326(0x2ab909b51540):ZOO_INFO@zookeeper_init_internal@1076: 
Initiating client connection, host=127.0.0.1:22181 sessionTimeout=1 
watcher=0x45d2f0 sessionId=0 sessionPasswd= context=0x7fff32d3f230 
flags=0]
 [exec] Log Message Received: [2015-06-08 
10:46:32,909:6326(0x2ab914200700):ZOO_INFO@check_events@2324: initiated 
connection to server [127.0.0.1:22181]]
 [exec] Log Message Received: [2015-06-08 
10:46:32,911:6326(0x2ab914200700):ZOO_INFO@check_events@2376: session 
establishment complete on server [127.0.0.1:22181], 
sessionId=0x101016b7072000f, negotiated timeout=1 ]
 [exec]  : elapsed 1000 : OK
 [exec] Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server 
started : elapsed 10112 : OK
 [exec] Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK
 [exec] Zookeeper_simpleSystem::testFirstServerDown : elapsed 1000 : OK
 [exec] Zookeeper_simpleSystem::testNullData : elapsed 1021 : OK
 [exec] Zookeeper_simpleSystem::testIPV6 : elapsed 1003 : OK
 [exec] Zookeeper_simpleSystem::testCreate : elapsed 1006 : OK
 [exec] Zookeeper_simpleSystem::testPath : elapsed 1012 : OK
 [exec] Zookeeper_simpleSystem::testPathValidation : elapsed 1036 : OK
 [exec] Zookeeper_simpleSystem::testPing : elapsed 17164 : OK
 [exec] Zookeeper_simpleSystem::testAcl : elapsed 1011 : OK
 [exec] Zookeeper_simpleSystem::testChroot : elapsed 3032 : OK
 [exec] Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper 
server started : elapsed 30219 : OK
 [exec] Zookeeper_simpleSystem::testHangingClient : elapsed 1021 : OK
 [exec] Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper 
server started ZooKeeper server started ZooKeeper server started : elapsed 
14365 : OK
 [exec] Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper 
server started ZooKeeper server started ZooKeeper server started : elapsed 
14376 : OK
 [exec] Zookeeper_simpleSystem::testGetChildren2 : elapsed 1028 : OK
 [exec] Zookeeper_simpleSystem::testLastZxid : elapsed 4510 : OK
 [exec] Zookeeper_simpleSystem::testRemoveWatchers ZooKeeper server started 
: elapsed 4163 : OK
 [exec] Zookeeper_readOnly::testReadOnly : elapsed 4089 : OK
 [exec] 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/tests/TestReconfig.cc:183:
 Assertion: equality assertion failed [Expected: 1, Actual  : 0]
 [exec] Failures !!!
 [exec] Run: 72   Failure total: 1   Failures: 1   Errors: 0
 [exec] FAIL: zktest-mt
 [exec] ==
 [exec] 1 of 2 tests failed
 [exec] Please report to u...@zookeeper.apache.org
 [exec] ==
 [exec] make[1]: Leaving directory 
`/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit'
 [exec] make[1]: *** [check-TESTS] Error 1
 [exec] make: *** [check-am] Error 2

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

Total time: 11 minutes 2 seconds
Build step 'Execute shell' marked build as failure
[FINDBUGS] Skipping publisher since build result is FAILURE
[WARNINGS] Skipping publisher since build result is FAILURE
Archiving artifacts
Sending artifact delta relative to ZooKeeper-trunk #2719
Archived 5 artifacts
Archive block size is 32768
Received 2 blocks and 18275953 bytes
Compression is 0.4%
Took 7 sec
Recording fingerprints
Recording test results
Publishing Javadoc
Email was triggered for: Failure
Sending email for trigger: Failure



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

ZooKeeper_branch34_openjdk7 - Build # 901 - Failure

[Apache Jenkins Server]

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 213763 lines...]
[junit] 2015-06-08 10:12:56,099 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2015-06-08 10:12:56,100 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2015-06-08 10:12:56,100 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2015-06-08 10:12:56,100 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - 
NIOServerCnxn factory exited run method
[junit] 2015-06-08 10:12:56,101 [myid:] - INFO  [main:ZooKeeperServer@441] 
- shutting down
[junit] 2015-06-08 10:12:56,101 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2015-06-08 10:12:56,101 [myid:] - INFO  
[main:PrepRequestProcessor@760] - Shutting down
[junit] 2015-06-08 10:12:56,101 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2015-06-08 10:12:56,101 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2015-06-08 10:12:56,102 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2015-06-08 10:12:56,102 [myid:] - INFO  
[main:FinalRequestProcessor@415] - shutdown of request processor complete
[junit] 2015-06-08 10:12:56,103 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2015-06-08 10:12:56,103 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2015-06-08 10:12:56,105 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2015-06-08 10:12:56,105 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2015-06-08 10:12:56,106 [myid:] - INFO  
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2015-06-08 10:12:56,106 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2015-06-08 10:12:56,106 [myid:] - INFO  [main:ZooKeeperServer@162] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_openjdk7/branch-3.4/build/test/tmp/test1151871548141760242.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_openjdk7/branch-3.4/build/test/tmp/test1151871548141760242.junit.dir/version-2
[junit] 2015-06-08 10:12:56,110 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2015-06-08 10:12:56,111 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - 
Accepted socket connection from /127.0.0.1:38366
[junit] 2015-06-08 10:12:56,111 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:38366
[junit] 2015-06-08 10:12:56,112 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2015-06-08 10:12:56,112 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1007] - Closed socket connection for client 
/127.0.0.1:38366 (no session established for client)
[junit] 2015-06-08 10:12:56,113 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2015-06-08 10:12:56,115 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2015-06-08 10:12:56,115 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2015-06-08 10:12:56,115 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2015-06-08 10:12:56,115 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2015-06-08 10:12:56,116 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 32637
[junit] 2015-06-08 10:12:56,116 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2015-06-08 10:12:56,116 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2015-06-08 10:12:56,116 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2015-06-08 10:12:56,183 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x14dd2a89f9e closed
[junit] 2015-06-08 10:12:56,183 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2015-06-08 10:12:56,183 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@512] - EventThread shut down for 
session: 0x14dd2a89f9e
[junit] 2015-06-08 10:12:56,183 [myid:] - INFO  

[jira] [Commented] (ZOOKEEPER-2193) reconfig command completes even if parameter is wrong obviously

[Yasuhito Fukuda (JIRA)]

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

Yasuhito Fukuda commented on ZOOKEEPER-2193:


Hi [~michim], [~shralex], thanks for your comments.
I have created new patch reflected comments from Alexander, and posted on 
reviewboard.
Please see the review https://reviews.apache.org/r/35204/

> reconfig command completes even if parameter is wrong obviously
> ---
>
> Key: ZOOKEEPER-2193
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2193
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: leaderElection, server
>Affects Versions: 3.5.0
> Environment: CentOS7 + Java7
>Reporter: Yasuhito Fukuda
>Assignee: Yasuhito Fukuda
> Attachments: ZOOKEEPER-2193-v2.patch, ZOOKEEPER-2193-v3.patch, 
> ZOOKEEPER-2193.patch
>
>
> Even if reconfig parameter is wrong, it was confirmed to complete.
> refer to the following.
> - Ensemble consists of four nodes
> {noformat}
> [zk: vm-101:2181(CONNECTED) 0] config
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> version=1
> {noformat}
> - add node by reconfig command
> {noformat}
> [zk: vm-101:2181(CONNECTED) 9] reconfig -add 
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> Committed new configuration:
> server.1=192.168.100.101:2888:3888:participant
> server.2=192.168.100.102:2888:3888:participant
> server.3=192.168.100.103:2888:3888:participant
> server.4=192.168.100.104:2888:3888:participant
> server.5=192.168.100.104:2888:3888:participant;0.0.0.0:2181
> version=30007
> {noformat}
> server.4 and server.5 of the IP address is a duplicate.
> In this state, reader election will not work properly.
> Besides, it is assumed an ensemble will be undesirable state.
> I think that need a parameter validation when reconfig.



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

Review Request 35204: ZOOKEEPER-2193: reconfig command completes even if parameter is wrong obviously

[Yasuhito Fukuda]

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

Review request for zookeeper.


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


Repository: zookeeper-git


Description
---

See ZOOKEEPER-2193


Diffs
-

  src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 
73fa4e67a09806c90a6037d9a170179cb806b896 
  src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java 
f15f831701f9c8514db5003ebd550cd3880b48c7 

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


Testing
---


Thanks,

Yasuhito Fukuda

Re: Improving latency monitoring

[Brian Brazil]

Hi,

Could I get a rough idea of when ZOOKEEPER-2093 might make it into an
official release?
I've currently got a hack doing a similar job, and want to plan for when I
can clean it up.

Thanks,
Brian

On 10 April 2015 at 11:42, Brian Brazil  wrote:

> On 10 April 2015 at 11:28, Rakesh R  wrote:
>
>>
>> Thanks Brian for the reminder. I'll go through the jira shortly.
>>
>
> Great, thanks!
>
>
>>
>> Best Regards,
>> Rakesh
>>
>> -Original Message-
>> From: Brian Brazil [mailto:brian.bra...@boxever.com]
>> Sent: 10 April 2015 15:44
>> To: dev@zookeeper.apache.org
>> Subject: Re: Improving latency monitoring
>>
>> Hi,
>>
>> I submitted my patch on
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2093
>> 4 months ago, I'd appreciate it if someone could review it.
>>
>> Thanks,
>> Brian
>>
>> On 7 January 2015 at 19:22, Brian Brazil 
>> wrote:
>>
>> > Hi,
>> >
>> > I want to track how my zookeeper's latency varies over time, the
>> > metrics currently offered by zookeeper only allow tracking of latency
>> > since startup rather than instantaneous values. With a cumulative
>> > count of requests and sum of their latencies, you can analyse their
>> > changes over time and calculate average latency for a given time period.
>> >
>> > Zookeeper already tracks the metrics needed but doesn't expose them,
>> > so I submitted https://issues.apache.org/jira/browse/ZOOKEEPER-2093 to
>> > allow them to be accessed via JMX so I can hook it into the rest of my
>> monitoring.
>> > Would it be possible to get this change reviewed?
>> >
>> >
>> > It would be nice to use System.nanoTime and track everything as
>> > seconds (the resolution may change again in the future) in a double,
>> > rather than being limited to millisecond precision. Do you think it's
>> > be reasonable to also switch the implementation over, while leaving
>> > the existing exports as integer milliseconds for backwards
>> compatibility?
>> >
>> > Thanks,
>> > Brian
>> >
>>
>
>

[VOTE] Apache ZooKeeper release 3.5.1-alpha candidate 2

[Michi Mutsuzaki]

This is the third release candidate for 3.5.1-alpha. The full release
notes is available at:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12326786

*** Please download, test and vote by June 26th 2015, 23:59 UTC+0. ***

Source files:
http://people.apache.org/~michim/zookeeper-3.5.1-alpha-candidate-2/

Maven staging repo:
https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.5.1-alpha/

The tag to be voted upon:
https://svn.apache.org/repos/asf/zookeeper/tags/release-3.5.1-rc2/

ZooKeeper's KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/zookeeper/KEYS

Should we release this candidate?

[jira] [Commented] (ZOOKEEPER-2163) Introduce new ZNode type: container

[Rakesh R (JIRA)]

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

Rakesh R commented on ZOOKEEPER-2163:
-

Hi [~rgs] [~michim] Since we merged the feature to 3.5 branch, good to modify 
the version of the new properties 
[znode.container.checkIntervalMs|https://github.com/apache/zookeeper/blob/trunk/src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml#L1392]
 and 
[znode.container.maxPerMinute|https://github.com/apache/zookeeper/blob/trunk/src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml#L1404]
 to {{New in 3.5.1}}, isn't it?



> Introduce new ZNode type: container
> ---
>
> Key: ZOOKEEPER-2163
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client, server
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.5.1, 3.6.0
>
> Attachments: zookeeper-2163.10.patch, zookeeper-2163.11.patch, 
> zookeeper-2163.12.patch, zookeeper-2163.13.patch, zookeeper-2163.14.patch, 
> zookeeper-2163.3.patch, zookeeper-2163.5.patch, zookeeper-2163.6.patch, 
> zookeeper-2163.7.patch, zookeeper-2163.8.patch, zookeeper-2163.9.patch
>
>
> BACKGROUND
> 
> A recurring problem for ZooKeeper users is garbage collection of parent 
> nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a 
> parent node under which participants create sequential nodes. When the 
> participant is done, it deletes its node. In practice, the ZooKeeper tree 
> begins to fill up with orphaned parent nodes that are no longer needed. The 
> ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can 
> become unstable due to the number of these nodes.
> CURRENT SOLUTIONS
> ===
> Apache Curator has a workaround solution for this by providing the Reaper 
> class which runs in the background looking for orphaned parent nodes and 
> deleting them. This isn’t ideal and it would be better if ZooKeeper supported 
> this directly.
> PROPOSAL
> =
> ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes 
> to contain child nodes. This is not optimum as EPHEMERALs are tied to a 
> session and the general use case of parent nodes is for PERSISTENT nodes. 
> This proposal adds a new node type, CONTAINER. A CONTAINER node is the same 
> as a PERSISTENT node with the additional property that when its last child is 
> deleted, it is deleted (and CONTAINER nodes recursively up the tree are 
> deleted if empty).
> CANONICAL USAGE
> 
> {code}
> while ( true) { // or some reasonable limit
> try {
> zk.create(path, ...);
> break;
> } catch ( KeeperException.NoNodeException e ) {
> try {
> zk.createContainer(containerPath, ...);
> } catch ( KeeperException.NodeExistsException ignore) {
>}
> }
> }
> {code}



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

[jira] [Updated] (ZOOKEEPER-2202) Cluster crashes when reconfig adds an unreachable observer

[Michi Mutsuzaki (JIRA)]

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

Michi Mutsuzaki updated ZOOKEEPER-2202:
---
Fix Version/s: (was: 3.5.1)
   3.5.2

> Cluster crashes when reconfig adds an unreachable observer
> --
>
> Key: ZOOKEEPER-2202
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2202
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Raul Gutierrez Segales
> Fix For: 3.5.2, 3.6.0
>
>
> While adding support for reconfig() in Kazoo 
> (https://github.com/python-zk/kazoo/pull/333) I found that the cluster can be 
> crashed if you add an observer whose election port isn't reachable (i.e.: 
> packets for that destination are dropped, not rejected). This will raise a 
> SocketTimeoutException which will bring down the PrepRequestProcessor:
> {code}
> 2015-06-02 14:37:16,473 [myid:3] - WARN  [ProcessThread(sid:3 
> cport:-1)::QuorumCnxManager@384] - Cannot open channel to 100 at election 
> address /8.8.8.8:38703
> java.net.SocketTimeoutException: connect timed out
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345)
> at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at 
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at 
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:369)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeer.connectNewPeers(QuorumPeer.java:1288)
> at 
> org.apache.zookeeper.server.quorum.QuorumPeer.setLastSeenQuorumVerifier(QuorumPeer.java:1315)
> at org.apache.zookeeper.server.quorum.Leader.propose(Leader.java:1056)
> at 
> org.apache.zookeeper.server.quorum.ProposalRequestProcessor.processRequest(ProposalRequestProcessor.java:78)
> at 
> org.apache.zookeeper.server.PrepRequestProcessor.pRequest(PrepRequestProcessor.java:877)
> at 
> org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:143)
> {code}
> A simple repro can be obtained by using the code in the referenced pull 
> request above and using 8.8.8.8:3888 (for example) instead of a free (but 
> closed) port in the loopback. 
> I think that adding an Observer (or a Participant) that isn't currently 
> reachable is a valid use case (i.e.: you are provisioning the machine and 
> it's not currently needed) so I think we could handle this with lower connect 
> timeouts, not sure. 



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

[jira] [Updated] (ZOOKEEPER-2163) Introduce new ZNode type: container

[Michi Mutsuzaki (JIRA)]

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

Michi Mutsuzaki updated ZOOKEEPER-2163:
---
Fix Version/s: (was: 3.5.0)
   3.6.0
   3.5.1

> Introduce new ZNode type: container
> ---
>
> Key: ZOOKEEPER-2163
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: c client, java client, server
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.5.1, 3.6.0
>
> Attachments: zookeeper-2163.10.patch, zookeeper-2163.11.patch, 
> zookeeper-2163.12.patch, zookeeper-2163.13.patch, zookeeper-2163.14.patch, 
> zookeeper-2163.3.patch, zookeeper-2163.5.patch, zookeeper-2163.6.patch, 
> zookeeper-2163.7.patch, zookeeper-2163.8.patch, zookeeper-2163.9.patch
>
>
> BACKGROUND
> 
> A recurring problem for ZooKeeper users is garbage collection of parent 
> nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a 
> parent node under which participants create sequential nodes. When the 
> participant is done, it deletes its node. In practice, the ZooKeeper tree 
> begins to fill up with orphaned parent nodes that are no longer needed. The 
> ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can 
> become unstable due to the number of these nodes.
> CURRENT SOLUTIONS
> ===
> Apache Curator has a workaround solution for this by providing the Reaper 
> class which runs in the background looking for orphaned parent nodes and 
> deleting them. This isn’t ideal and it would be better if ZooKeeper supported 
> this directly.
> PROPOSAL
> =
> ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes 
> to contain child nodes. This is not optimum as EPHEMERALs are tied to a 
> session and the general use case of parent nodes is for PERSISTENT nodes. 
> This proposal adds a new node type, CONTAINER. A CONTAINER node is the same 
> as a PERSISTENT node with the additional property that when its last child is 
> deleted, it is deleted (and CONTAINER nodes recursively up the tree are 
> deleted if empty).
> CANONICAL USAGE
> 
> {code}
> while ( true) { // or some reasonable limit
> try {
> zk.create(path, ...);
> break;
> } catch ( KeeperException.NoNodeException e ) {
> try {
> zk.createContainer(containerPath, ...);
> } catch ( KeeperException.NodeExistsException ignore) {
>}
> }
> }
> {code}



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

[jira] [Updated] (ZOOKEEPER-2209) A .NET C# version of ZooKeeper client 3.4.6 release

[Shay Hazor (JIRA)]

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

Shay Hazor updated ZOOKEEPER-2209:
--
Remaining Estimate: 168h  (was: 336h)
 Original Estimate: 168h  (was: 336h)

> A .NET C# version of ZooKeeper client 3.4.6 release
> ---
>
> Key: ZOOKEEPER-2209
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2209
> Project: ZooKeeper
>  Issue Type: New Feature
>Affects Versions: 3.4.6
> Environment: .NET
>Reporter: Shay Hazor
>  Labels: .NET, async, c#
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Inspired by the work of ewhauser .
> I propose a C# Client that supports the current stable version of ZK 3.4.6.
> It was built by using static code conversion tools followed by manual editing 
> and C# implementations of java selector and other java constructs. 
> A great measure was taken to follow the logic of the java version. In fact, 
> the code is almost identical. Thus allowing easy evolution alongside the java 
> version. 
> Main features:
> * .NET async version of every ZK method
> * all relevant unit tests have been converted and passing consistently
> * recipes are included, will be converted to async soon
> * nuget package



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

[jira] [Created] (ZOOKEEPER-2209) A .NET C# version of ZooKeeper client 3.4.6 release

[Shay Hazor (JIRA)]

Shay Hazor created ZOOKEEPER-2209:
-

 Summary: A .NET C# version of ZooKeeper client 3.4.6 release
 Key: ZOOKEEPER-2209
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2209
 Project: ZooKeeper
  Issue Type: New Feature
Affects Versions: 3.4.6
 Environment: .NET
Reporter: Shay Hazor


Inspired by the work of ewhauser .
I propose a C# Client that supports the current stable version of ZK 3.4.6.
It was built by using static code conversion tools followed by manual editing 
and C# implementations of java selector and other java constructs. 
A great measure was taken to follow the logic of the java version. In fact, the 
code is almost identical. Thus allowing easy evolution alongside the java 
version. 

Main features:
* .NET async version of every ZK method
* all relevant unit tests have been converted and passing consistently
* recipes are included, will be converted to async soon
* nuget package




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