[jira] [Updated] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2597: -- Assignee: (was: Edward Ribeiro) > 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] [Comment Edited] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567369#comment-15567369 ] Edward Ribeiro edited comment on ZOOKEEPER-2597 at 10/12/16 3:07 AM: - Hi Ben, I have been unable to work on this and other issues lately (few weeks). I was hoping to resume work on it today... but... not yet. :( And I know this script is important to define git based workflow, so feel free to take a work on it. :) if you don't mind, I can help you (will start by answering the questions on my previous PR). PS: see that it is a port of *kafka-merge-pr.py* (that, by its turn, is lifted off *spark_merge_pr.py*) as so you may want to reference it. https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py was (Author: eribeiro): Hi Ben, I have been unable to work on this and other issues lately (few weeks). I was hoping to resume work on it today... but... not yet. :( And I know this script is important to define git based workflow, so feel free to take a stab at it. :) PS: see that it is a port of kafka-merge.py so you may want to reference it. > 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567369#comment-15567369 ] Edward Ribeiro commented on ZOOKEEPER-2597: --- Hi Ben, I have been unable to work on this and other issues lately (few weeks). I was hoping to resume work on it today... but... not yet. :( And I know this script is important to define git based workflow, so feel free to take a stab at it. :) PS: see that it is a port of kafka-merge.py so you may want to reference it. > 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15558797#comment-15558797 ] Edward Ribeiro commented on ZOOKEEPER-2597: --- [~breed], sorry for the awkward delay! The PR is up now as shown above. :) Cheers! > 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-2169) Enable creation of nodes with TTLs
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552962#comment-15552962
]
Edward Ribeiro commented on ZOOKEEPER-2169:
---
Fortunately, generating an updated patch from Github it's a matter of appending
a ".diff" of ".patch" to the PR URL. ;)
https://github.com/apache/zookeeper/pull/82.diff
will work with {{git apply}}.
/cc [~randgalt]
Cheers!
> Enable creation of nodes with TTLs
> --
>
> Key: ZOOKEEPER-2169
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2169
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client, java client, jute, server
>Affects Versions: 3.6.0
>Reporter: Camille Fournier
>Assignee: Jordan Zimmerman
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-2169-2.patch, ZOOKEEPER-2169-3.patch,
> ZOOKEEPER-2169-4.patch, ZOOKEEPER-2169-5.patch, ZOOKEEPER-2169.patch
>
>
> As a user, I would like to be able to create a node that is NOT tied to a
> session but that WILL expire automatically if action is not taken by some
> client within a time window.
> I propose this to enable clients interacting with ZK via http or other "thin
> clients" to create ephemeral-like nodes.
> Some ideas for the design, up for discussion:
> The node should support all normal ZK node operations including ACLs,
> sequential key generation, etc, however, it should not support the ephemeral
> flag. The node will be created with a TTL that is updated via a refresh
> operation.
> The ZK quorum will watch this node similarly to the way that it watches for
> session liveness; if the node is not refreshed within the TTL, it will expire.
> QUESTIONS:
> 1) Should we let the refresh operation set the TTL to a different base value?
> 2) If so, should the setting of the TTL to a new base value cause a watch to
> fire?
> 3) Do we want to allow these nodes to have children or prevent this similar
> to ephemeral nodes?
--
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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15552924#comment-15552924 ] Edward Ribeiro commented on ZOOKEEPER-2597: --- [~breed], indeed. :) Please, let me know what can I do to speed up the merging of this tool. PS: I am gonna do a PR tonight at last. > 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-2593) Enforce the quota limit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513486#comment-15513486
]
Edward Ribeiro commented on ZOOKEEPER-2593:
---
{quote}
1. enforce the quota limit at more granular level. can we add
enforce.number.quota and enforce.byte.quota ?
I think there is need to change the implementation as well.
{quote}
Agree.
{quote}
we should check the limit at centralized place like in {{
PrepRequestProcessor}}. If we check the limit in DataTree which is at every
server then the exceptions can not be passed to clients.
{quote}
Agree.
> Enforce the quota limit
> ---
>
> Key: ZOOKEEPER-2593
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2593
> Project: ZooKeeper
> Issue Type: New Feature
> Components: java client, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>
> Currently in ZooKeeper when quota limit exceeds, a warning is logged. There
> are many user scenarios where it is desired to throw exception in case quota
> limits exceed.
> We should make it configurable whether to throw exception or just log the
> warning when quota limits exceed.
> *Implementation:*
> add new properties
> {code}
> enforce.number.quota
> enforce.byte.quota
> {code}
> add new error codes
> {code}
> KeeperException.Code.NUMBERQUOTAEXCEED
> KeeperException.Code.BYTEQUOTAEXCEED
> {code}
> add new exception
> {code}
> KeeperException.NumberQuotaExceedException
> KeeperException.ByteQuotaExceedException
> {code}
>
> *Basic Scenarios:*
> # If enforce.number.quota=true and number quota exceed, then server should
> send NUMBERQUOTAEXCEED error code and client should throw
> NumberQuotaExceedException
> # If enforce.byte.quota=true and byte quota exceed, then server should send
> BYTEQUOTAEXCEED error code and client should throw ByteQuotaExceedException
> *Impacted APIs:*
> create
> setData
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2496) When inside a transaction, some exceptions do not have path information set.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490356#comment-15490356 ] Edward Ribeiro edited comment on ZOOKEEPER-2496 at 9/21/16 7:43 PM: Hey [~kazuakibanzai], could you please confirm if this issue is not a duplicate of https://issues.apache.org/jira/browse/ZOOKEEPER-2276 ? Thanks update: /cc [~arshad.mohammad] was (Author: eribeiro): Hey [~kazuakibanzai], could you please confirm if this issue is not a duplicate of https://issues.apache.org/jira/browse/ZOOKEEPER-2276 ? Thanks > When inside a transaction, some exceptions do not have path information set. > > > Key: ZOOKEEPER-2496 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2496 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 >Reporter: Kazuaki Banzai > Attachments: transactionException.patch > > > If a client tries to execute some illegal operations inside a transaction, > ZooKeeper throws an exception. > Some exceptions such as NodeExistsException should have a path to indicate > where the exception occurred. > ZooKeeper clients can get the path by calling method getPath. > However, this method returns null if the exception occurs inside a > transaction. > For example, when a client calls create /a and create /a in a transaction, > ZooKeeper throws NodeExistsException but getPath returns null. > In normal operation (outside transactions), the path information is set > correctly. > The patch only shows this bug occurs with NoNode exception and NodeExists > exception, > but this bug seems to occur with any exception which needs a path information: > When an error occurred in a transaction, ZooKeeper creates an ErrorResult > instance to represent error result. > However, the ErrorResult class doesn't have a field for a path where an error > occurred(See src/java/main/org/apache/zookeeper/OpResult.java for more > details). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2597) Add script to merge PR from Apache git repo to Github
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510259#comment-15510259
]
Edward Ribeiro commented on ZOOKEEPER-2597:
---
Hi [~phunt],
I updated the left over kafka reference (it was a comment). My grep finds
didn't bring anymore, but let me know if there's yet another one. I have been
working with Python for just about a year now, so I would *really* appreciate
any review/feedback on this script. Thanks!
AFAIK (mostly from reading the code for it), this tool is used to have Github
PRs mergeed into Apache git repo and then the PR is closed on Github side
(updating the JIRA, etc). Committers can either use this tool or merge the
patch directly on Apache repo, it seems.
{quote}
What documents should I look at re using/workflow for this tool? Is there a
particular page(s) from Kafka that we will need to incorporate into our
docs/workflow?
{quote}
The following docs provide an sneak peak into their process.
https://cwiki.apache.org/confluence/display/KAFKA/Patch+submission+and+review
https://cwiki.apache.org/confluence/display/KAFKA/Merging+Github+Pull+Requests
https://cwiki.apache.org/confluence/display/KAFKA/Manual+Commit+Workflow
https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes
{quote}
What are they and who will be responsible for updating (assuming it's cwiki?)
{quote}
Idk if I have access, but I can update the cwiki if this tool is incorporated.
{quote}
Also, where will this tool be made available? Is it committed to git (if so
where) or is it a d/l'able for committers, available from the cwiki workflow
page... ?
{quote}
Very good question. Kafka project has it on the root folder
https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py , but I myself
would prefer to have it downloadable elsewhere...
Further references as discussed in the mailing list:
Blogs from Infra:
https://blogs.apache.org/infra/entry/github_pull_request_builds_now
https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
> 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2597: -- Attachment: (was: 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 > > > 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
[ 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2597: -- Summary: Add script to merge PR from Apache git repo to Github (was: Add script to merge PR Apache git repo to Github) > 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 Apache git repo to Github
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2597: -- Summary: Add script to merge PR Apache git repo to Github (was: Add script to merge PR from Github to Apache git repo) > Add script to merge PR 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 Github to Apache git repo
[ 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 The original file used is at: https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py > Add script to merge PR from Github to Apache git repo > - > > 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] [Created] (ZOOKEEPER-2597) Add script to merge PR from Github to Apache git repo
Edward Ribeiro created ZOOKEEPER-2597: - Summary: Add script to merge PR from Github to Apache git repo 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 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-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2521: -- Assignee: (was: Edward Ribeiro) > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Priority: Minor > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506875#comment-15506875
]
Edward Ribeiro commented on ZOOKEEPER-2521:
---
Oh, exception and the message come from standard java API:
https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html#load(java.io.InputStream,%20char[])
It cannot figured out if the keyStore is corrupted or the password is
incorrect. Same for the odd {{IOException}}. I guess the rationale was because
keyStore is a file so it cannot read the file for the reasons I alluded. Even
so, odd.
> space should be truncated while reading password for keystore/truststore
> which is required to configure while SSL enabled
> -
>
> Key: ZOOKEEPER-2521
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch
>
>
> space should be truncated while reading password for keystore/truststore
> which is required to configure while SSL enabled.
> As of now if we configure the password with any heading/trailing space, the
> zookeeper server will fail to start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506799#comment-15506799
]
Edward Ribeiro commented on ZOOKEEPER-2521:
---
Yup, agree.
Currently the error message bubble up is:
{quote}
org.apache.zookeeper.common.X509Exception$KeyManagerException:
java.io.IOException: Keystore was tampered with, or password was incorrect
{quote}
Isn't that enough?
> space should be truncated while reading password for keystore/truststore
> which is required to configure while SSL enabled
> -
>
> Key: ZOOKEEPER-2521
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.1
>Reporter: Rakesh Kumar Singh
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch
>
>
> space should be truncated while reading password for keystore/truststore
> which is required to configure while SSL enabled.
> As of now if we configure the password with any heading/trailing space, the
> zookeeper server will fail to start.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2521: -- Attachment: ZOOKEEPER-2521.2.patch > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2521: -- Attachment: (was: ZOOKEEPER-2521.2.patch) > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2521: -- Attachment: ZOOKEEPER-2521.2.patch > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2521.2.patch, ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504559#comment-15504559 ] Edward Ribeiro commented on ZOOKEEPER-2521: --- Fair enough. That's ok to you, [~rakeshsingh]? > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Attachments: ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2593) Enforce the quota limit
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503986#comment-15503986
]
Edward Ribeiro commented on ZOOKEEPER-2593:
---
Hey [~arshad.mohammad], this is a duplicate of ZOOKEEPER-451
> Enforce the quota limit
> ---
>
> Key: ZOOKEEPER-2593
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2593
> Project: ZooKeeper
> Issue Type: New Feature
> Components: java client, server
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
>
> Currently in ZooKeeper when quota limit exceeds, a warning is logged. There
> are many user scenarios where it is desired to throw exception in case quota
> limits exceed.
> We should make it configurable whether to throw exception or just log the
> warning when quota limits exceed.
> *Implementation:*
> add new properties
> {code}
> enforce.number.quota
> enforce.byte.quota
> {code}
> add new error codes
> {code}
> KeeperException.Code.NUMBERQUOTAEXCEED
> KeeperException.Code.BYTEQUOTAEXCEED
> {code}
> add new exception
> {code}
> KeeperException.NumberQuotaExceedException
> KeeperException.ByteQuotaExceedException
> {code}
>
> *Basic Scenarios:*
> # If enforce.number.quota=true and number quota exceed, then server should
> send NUMBERQUOTAEXCEED error code and client should throw
> NumberQuotaExceedException
> # If enforce.byte.quota=true and byte quota exceed, then server should send
> BYTEQUOTAEXCEED error code and client should throw ByteQuotaExceedException
> *Impacted APIs:*
> create
> setData
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503712#comment-15503712 ] Edward Ribeiro commented on ZOOKEEPER-2552: --- Ping [~rakeshr]. :) > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Edward Ribeiro > Fix For: 3.4.10 > > Attachments: ZOOKEEPER-2552.patch, closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503698#comment-15503698 ] Edward Ribeiro commented on ZOOKEEPER-2521: --- Yep, makes sense. Thanks for pointing out! Particularly, I think passwords with spaces at beginning/end can lead to the all sorts of headaches during maintenance and operation. Like the one that _probably_ motivated this issue. But I am fine about *_discarding_* this patch/issue. Would like to hear from the committers and users (/cc [~arshad.mohammad]). +1 about documenting this restriction if we apply this patch. > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Attachments: ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro resolved ZOOKEEPER-2591.
---
Resolution: Not A Bug
{{OpCode.deleteContainer}} is asynchronously deleted by
{{ContainerManager.checkContainers()}} and it doesn't need to check the ACL
because it performs a garbage collection if the znode is empty. Therefore, a
client delete operation is issued as a {{OpsCode.delete}} and handled as usual,
including the ACL checking. The first example posted on this issue was also
wrong in that delete does check the ACL rights of the parent nor the child.
> 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.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2591:
--
Description:
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}
was:
Container nodes check the ACL before creation, but the deletion doesn't check
the ACL rights. The code below succeeds even tough we removed ACL access
permissions for "/a".
{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
ArrayList list = new ArrayList<>();
list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/a", list, -1);
zk.delete("/a", -1);
{code}
> 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.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500156#comment-15500156
]
Edward Ribeiro commented on ZOOKEEPER-2439:
---
Hi [~hanm]!
{quote}
Should we check ACL in FinalRequestProcessor?
{quote}
I hope so! :) I considered this solution too, but sidetracked because I am
unsure about transactional guarantees, particularly the _*sync request to
disk*_ performed by {{SyncRequestProcessor}}.
Note: by the way, my stab at a solution (just a sketch, really) most probably
breaks on parallel unit test running due to the use of static mutable fields.
{quote}
note we already check ACL in FinalRequestProcessor (example) for some ops, but
not all, not sure why.
{quote}
The *non state changing* operations (exists, getData, getChildren, etc) follow
a slightly different, more straightforward, path down the processing pipeline
while transactional, *state changing*, operations (setData, delete, setACL,
etc) perform a series of extra operations, as expected. Therefore, it looks
like {{FinalRequestProcessor}} is currently checking the ACL permissions for
non transactional check/read operations (even tough _exists()_ operation is
lacking ACL check, a bug, imho) while the transactional operations are handled
by {{PrepRequestProcessor.pRequest2Txn}} nowadays.
> The order of asynchronous setACL is not correct.
>
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
> Labels: acl
> Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper
> server is always ordered, as both synchronous and asynchronous commands are
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL
> between (1) and (2), the synchronous case works correctly but the
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test
> sometimes fails as well but only rarely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission
Edward Ribeiro created ZOOKEEPER-2591:
-
Summary: The deletion of Container znode doesn't check ACL delete
permission
Key: ZOOKEEPER-2591
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
Project: ZooKeeper
Issue Type: Bug
Components: security, server
Reporter: Edward Ribeiro
Assignee: Edward Ribeiro
Container nodes check the ACL before creation, but the deletion doesn't check
the ACL rights. The code below succeeds even tough we removed ACL access
permissions for "/a".
{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
ArrayList list = new ArrayList<>();
list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/a", list, -1);
zk.delete("/a", -1);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2590) setACL doesn't affect exists() operation
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2590:
--
Description:
As hinted
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
even if a parent znode path has restricted READ access it's possible to issue
an exists() operation on any child znode of that given path.
For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it
removes ACL rights to "/":
{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/", acls, -1);
Stat r = zk.exists("/a", false);
{code}
Also, in the above example, what if the removed READ access for "/a"? Should we
allow a call to exists("/a") to succeed even if it returns the znode metadata
info?
was:
As hinted
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
even if a parent znode path has restricted READ access it's possible to issue
an exists() operation on any child znode of that given path.
For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it
removes ACL rights to "/":
{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/", acls, -1);
Stat r = zk.exists("/a", false);
{code}
> setACL doesn't affect exists() operation
>
>
> Key: ZOOKEEPER-2590
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
> Labels: acl, security
>
> As hinted
> [here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
> even if a parent znode path has restricted READ access it's possible to
> issue an exists() operation on any child znode of that given path.
> For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough
> it removes ACL rights to "/":
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
> ArrayList acls = new ArrayList<>();
> acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", acls, -1);
> Stat r = zk.exists("/a", false);
> {code}
> Also, in the above example, what if the removed READ access for "/a"? Should
> we allow a call to exists("/a") to succeed even if it returns the znode
> metadata info?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2590) setACL doesn't affect exists() operation
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro reassigned ZOOKEEPER-2590:
-
Assignee: Edward Ribeiro
> setACL doesn't affect exists() operation
>
>
> Key: ZOOKEEPER-2590
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
> Labels: acl, security
>
> As hinted
> [here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
> even if a parent znode path has restricted READ access it's possible to
> issue an exists() operation on any child znode of that given path.
> For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough
> it removes ACL rights to "/":
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
> ArrayList acls = new ArrayList<>();
> acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", acls, -1);
> Stat r = zk.exists("/a", false);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2590) setACL doesn't affect exists() operation
Edward Ribeiro created ZOOKEEPER-2590:
-
Summary: setACL doesn't affect exists() operation
Key: ZOOKEEPER-2590
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2590
Project: ZooKeeper
Issue Type: Bug
Reporter: Edward Ribeiro
As hinted
[here|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java#L298],
even if a parent znode path has restricted READ access it's possible to issue
an exists() operation on any child znode of that given path.
For example, the snippet below doesn't throw {{NoAuthExceptio}}, even tough it
removes ACL rights to "/":
{code}
zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
ArrayList acls = new ArrayList<>();
acls.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
zk.setACL("/", acls, -1);
Stat r = zk.exists("/a", false);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496963#comment-15496963
]
Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 6:07 PM:
I am attaching a crude and possible buggy stab at a solution.
My idea with this patch is just to *bootstrap* the discussion about possible
fixes, so *don't rely on it for being complete (what about multiop?), correct
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly
provided, for what's worth. :)
PS: TBH, I *don't* like the idea of 'throttling' the pipeline until setACL
completes, so I am more than open to hear what you have to say.
was (Author: eribeiro):
I am attaching a crude and possible buggy stab at a solution.
My idea with this patch is just to *bootstrap* the discussion about possible
fixes, so *don't rely on it for being complete (what about multiop?), correct
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly
provided, for what's worth. :)
> The order of asynchronous setACL is not correct.
>
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
> Labels: acl
> Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper
> server is always ordered, as both synchronous and asynchronous commands are
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL
> between (1) and (2), the synchronous case works correctly but the
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test
> sometimes fails as well but only rarely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2439:
--
Attachment: ZOOKEEPER-2439-WIP.patch
I am attaching a crude and possible buggy stab at a solution.
My idea with this patch is just to *bootstrap* the discussion about possible
fixes, so *don't rely on it for being complete (what about multiop?), correct
or comprehensive*, but it passed the {{AsyncSetACLTest}} that Kazuaki kindly
provided, for what's worth. :)
> The order of asynchronous setACL is not correct.
>
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
> Labels: acl
> Attachments: ZOOKEEPER-2439-WIP.patch, ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper
> server is always ordered, as both synchronous and asynchronous commands are
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE another API is called, asynchronous
> setACL is applied AFTER another API.
> For example, if a client calls
> (1) asynchronous setACL to remove all permissions of node "/" and
> (2) synchronous create to create node "/a",
> synchronous create should fail, but it succeeds on Ubuntu.
> (We can see all permissions of node "/" are removed when the client calls
> getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL
> between (1) and (2), the synchronous case works correctly but the
> asynchronous case still produces the bug.)
> The attached unit test reproduces this scenario. It fails on Linux Ubuntu but
> succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test
> sometimes fails as well but only rarely.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496588#comment-15496588
]
Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 3:37 PM:
Hi [~kazuakibanzai],
I took some time to dig this problem and I *guess* I've found the root cause.
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear
from some ZK committers as to deny or confirm my idea (and took the liberty of
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]
First and foremost, *huge thanks* for the patch to simulate the bug, it helped
a lot. Well, let's start: in a nutshell, the server side ZK is an ordered
processing pipeline of RequestProcessors, where each processor is handled by a
different Thread. The one that is interesting to this particular case looks
like this (I am a newbie, so I may get something wrong):
{code}
request --> PrepRequestProcessor > SyncRequestsProcessor
--> FinalRequestProcessor --> [request applied and committed]
{code}
*KEEP THIS IN MIND:* A request is committed to ZK database as well as having
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}}
without any exception.
a. One request can be currently being processed at {{PrepRequestProcessor}}
while another one is either {{SyncRequestsProcessor}} or
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests,
one in each step of the pipeline under high load, for example.
b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is
well formed as well as authorization and ACL permissions (it makes sense as
SyncRequestProcessor, among other things, saves the log file and we wouldn't
want to record an invalid request on command log, right?). *KEEP THIS IN MIND
TOO:* ACL checks are done at the first stage of the pipeline.
*_So, the problem you described can be summarised as such:_*
1. a setACL request that removes access to '/' (let's call it REQ1) is sent
asynchronously, followed by a create a znode under '/a' request (let's call it
REQ2). Both are enqueued in order and arrive in this order on the server side.
2. REQ1 passes {{PrepRequestProcessor}}.
3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that
REQ2 has the ACL rights to create the node, because REQ1 was not committed to
ZK DB yet (it's in the middle of the pipeline).
4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent
REQ2 from being applied! Remember the permission was check on
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still
ongoing.
*_Now let's see why some scenarios that explain your unit test:_*
Case 1: The sync ACL call is, well, synchronous so, it wait for a response
before sending the next command (createNode). Therefore, REQ1 completes the
pipeline before REQ2 even reaches the it and the createNode is rejected as
expected.
Case 2. If you put a sleep between async setACL and createNode then you gave
some time to REQ1 finish the pipeline because REQ2 will be inserted into the
client outgoing queue after the sleep time. Again, this succeeds by rejecting
the createNode command.
Case 3. If you insert async or sync setACL commands before the createNode you
are "stuffing" additional commands between setACL and createNode. Again giving
a chance of setACL finishes before the createdNode reaches the first stage of
the pipeline. Then again, it works as expected (the createNode is rejected).
Finally, another conjecture I have is that this setACL/createNode behavior
could happen if with synchronous setACL. If we had two clients, the first one
could issue a sync setACL and the second one a createNode, and with the right
timing they would be enqueued as explained above.
Does it make sense?
was (Author: eribeiro):
Hi [~kazuakibanzai],
I took some time to dig this problem and I *guess* I've found the root cause.
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear
from some ZK committers as to deny or confirm my idea (and took the liberty of
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]
First and foremost, *huge thanks* for the patch to simulate the bug, it helped
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing
pipeline of RequestProcessors. The one that is interesting to this particular
case looks like this (I am a newbie, so I may get something wrong):
{code}
request --> PrepRequestProcessor > SyncRequestsProcessor
--> FinalRequestProcessor --> [request applied and committed]
{code}
*KEEP THIS IN MIND:* A request is committed to
[jira] [Comment Edited] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496588#comment-15496588
]
Edward Ribeiro edited comment on ZOOKEEPER-2439 at 9/16/16 3:35 PM:
Hi [~kazuakibanzai],
I took some time to dig this problem and I *guess* I've found the root cause.
*Disclaimer: I can be totally wrong on my assumptions, so would love to hear
from some ZK committers as to deny or confirm my idea (and took the liberty of
marking them on this message, sorry guys).* /cc [~fpj], [~breed], [~phunt]
First and foremost, *huge thanks* for the patch to simulate the bug, it helped
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing
pipeline of RequestProcessors. The one that is interesting to this particular
case looks like this (I am a newbie, so I may get something wrong):
{code}
request --> PrepRequestProcessor > SyncRequestsProcessor
--> FinalRequestProcessor --> [request applied and committed]
{code}
*KEEP THIS IN MIND:* A request is committed to ZK database as well as having
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}}
without any exception.
a. One request can be currently being processed at {{PrepRequestProcessor}}
while another one is either {{SyncRequestsProcessor}} or
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests,
one in each step of the pipeline under high load, for example.
b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is
well formed as well as authorization and ACL permissions (it makes sense as
SyncRequestProcessor, among other things, saves the log file and we wouldn't
want to record an invalid request on command log, right?). *KEEP THIS IN MIND
TOO:* ACL checks are done at the first stage of the pipeline.
*_So, the problem you described can be summarised as such:_*
1. a setACL request that removes access to '/' (let's call it REQ1) is sent
asynchronously, followed by a create a znode under '/a' request (let's call it
REQ2). Both are enqueued in order and arrive in this order on the server side.
2. REQ1 passes {{PrepRequestProcessor}}.
3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that
REQ2 has the ACL rights to create the node, because REQ1 was not committed to
ZK DB yet (it's in the middle of the pipeline).
4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent
REQ2 from being applied! Remember the permission was check on
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still
ongoing.
*_Now let's see why some scenarios that explain your unit test:_*
Case 1: The sync ACL call is, well, synchronous so, it wait for a response
before sending the next command (createNode). Therefore, REQ1 completes the
pipeline before REQ2 even reaches the it and the createNode is rejected as
expected.
Case 2. If you put a sleep between async setACL and createNode then you gave
some time to REQ1 finish the pipeline because REQ2 will be inserted into the
client outgoing queue after the sleep time. Again, this succeeds by rejecting
the createNode command.
Case 3. If you insert async or sync setACL commands before the createNode you
are "stuffing" additional commands between setACL and createNode. Again giving
a chance of setACL finishes before the createdNode reaches the first stage of
the pipeline. Then again, it works as expected (the createNode is rejected).
Finally, another conjecture I have is that this setACL/createNode behavior
could happen if with synchronous setACL. If we had two clients, the first one
could issue a sync setACL and the second one a createNode, and with the right
timing they would be enqueued as explained above.
Does it make sense?
was (Author: eribeiro):
Hi [~kazuakibanzai],
I took some time to dig this problem and I *guess* I've found the root cause.
*Disclaimer: I can be totally wrong on my assumptions, so would love to see
some ZK committers about this as to deny or confirm my idea (and took the
liberty of marking them on this message, sorry guys).* /cc [~fpj], [~breed],
[~phunt]
First and foremost, *huge thanks* for the patch to simulate the bug, it helped
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing
pipeline of RequestProcessors. The one that is interesting to this particular
case looks like this (I am a newbie, so I may get something wrong):
{code}
request --> PrepRequestProcessor > SyncRequestsProcessor
--> FinalRequestProcessor --> [request applied and committed]
{code}
*KEEP THIS IN MIND:* A request is committed to ZK database as well as having
the logs and snapshots
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2439: -- Assignee: (was: Edward Ribeiro) > The order of asynchronous setACL is not correct. > > > Key: ZOOKEEPER-2439 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 > Environment: Linux Ubuntu > Mac OS X >Reporter: Kazuaki Banzai > Labels: acl > Attachments: ZOOKEEPER-2439.patch > > > Within a given client connection, the execution of commands on the ZooKeeper > server is always ordered, as both synchronous and asynchronous commands are > dispatched through queuePacket (directly or indirectly). > In other words, Zookeeper guarantees sequential consistency: updates from a > client will be applied in the order that they were sent. > However, the order of asynchronous setACL is not correct on Ubuntu. > When asynchronous setACL is called BEFORE another API is called, asynchronous > setACL is applied AFTER another API. > For example, if a client calls > (1) asynchronous setACL to remove all permissions of node "/" and > (2) synchronous create to create node "/a", > synchronous create should fail, but it succeeds on Ubuntu. > (We can see all permissions of node "/" are removed when the client calls > getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL > between (1) and (2), the synchronous case works correctly but the > asynchronous case still produces the bug.) > The attached unit test reproduces this scenario. It fails on Linux Ubuntu but > succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test > sometimes fails as well but only rarely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15496588#comment-15496588
]
Edward Ribeiro commented on ZOOKEEPER-2439:
---
Hi [~kazuakibanzai],
I took some time to dig this problem and I *guess* I've found the root cause.
*Disclaimer: I can be totally wrong on my assumptions, so would love to see
some ZK committers about this as to deny or confirm my idea (and took the
liberty of marking them on this message, sorry guys).* /cc [~fpj], [~breed],
[~phunt]
First and foremost, *huge thanks* for the patch to simulate the bug, it helped
a lot. Well, let's start: in a nutshell, the server side ZK ordered processing
pipeline of RequestProcessors. The one that is interesting to this particular
case looks like this (I am a newbie, so I may get something wrong):
{code}
request --> PrepRequestProcessor > SyncRequestsProcessor
--> FinalRequestProcessor --> [request applied and committed]
{code}
*KEEP THIS IN MIND:* A request is committed to ZK database as well as having
the logs and snapshots updated if it arrives at the {{FinalRequestProcessor}}
without any exception.
a. One request can be currently being processed at {{PrepRequestProcessor}}
while another one is either {{SyncRequestsProcessor}} or
{{FinalRequestsProcessor}}. In fact, I guess that we can have three requests,
one in each step of the pipeline under high load, for example.
b. At {{PrepRequestProcessor}} ZK checks if the znode path of the request is
well formed as well as authorization and ACL permissions (it makes sense as
SyncRequestProcessor, among other things, saves the log file and we wouldn't
want to record an invalid request on command log, right?). *KEEP THIS IN MIND
TOO:* ACL checks are done at the first stage of the pipeline.
*_So, the problem you described can be summarised as such:_*
1. a setACL request that removes access to '/' (let's call it REQ1) is sent
asynchronously, followed by a create a znode under '/a' request (let's call it
REQ2). Both are enqueued in order and arrive in this order on the server side.
2. REQ1 passes {{PrepRequestProcessor}}.
3. While REQ1 is at {{SyncRequestsProcessor}}, REQ 2 arrives at
{{PrepRequestProcessor}}. {{PrepRequestProcessor}} checks ZK DB and see that
REQ2 has the ACL rights to create the node, because REQ1 was not committed to
ZK DB yet (it's in the middle of the pipeline).
4. When REQ1 is finally committed on ZK DB, REQ1 is just behind it in the
pipeline, so it also gets committed to the ZK DB even tough REQ1 would prevent
REQ2 from being applied! Remember the permission was check on
{{PrepRequestProcessor}}, the first stage of the pipeline, when REQ1 was still
ongoing.
*_Now let's see why some scenarios that explain your unit test:_*
Case 1: The sync ACL call is, well, synchronous so, it wait for a response
before sending the next command (createNode). Therefore, REQ1 completes the
pipeline before REQ2 even reaches the it and the createNode is rejected as
expected.
Case 2. If you put a sleep between async setACL and createNode then you gave
some time to REQ1 finish the pipeline because REQ2 will be inserted into the
client outgoing queue after the sleep time. Again, this succeeds by rejecting
the createNode command.
Case 3. If you insert async or sync setACL commands before the createNode you
are "stuffing" additional commands between setACL and createNode. Again giving
a chance of setACL finishes before the createdNode reaches the first stage of
the pipeline. Then again, it works as expected (the createNode is rejected).
Finally, another conjecture I have is that this setACL/createNode behavior
could happen if with synchronous setACL. If we had two clients, the first one
could issue a sync setACL and the second one a createNode, and with the right
timing they would be enqueued as explained above.
Does it make sense?
> The order of asynchronous setACL is not correct.
>
>
> Key: ZOOKEEPER-2439
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.5.1
> Environment: Linux Ubuntu
> Mac OS X
>Reporter: Kazuaki Banzai
>Assignee: Edward Ribeiro
> Labels: acl
> Attachments: ZOOKEEPER-2439.patch
>
>
> Within a given client connection, the execution of commands on the ZooKeeper
> server is always ordered, as both synchronous and asynchronous commands are
> dispatched through queuePacket (directly or indirectly).
> In other words, Zookeeper guarantees sequential consistency: updates from a
> client will be applied in the order that they were sent.
> However, the order of asynchronous setACL is not correct on Ubuntu.
> When asynchronous setACL is called BEFORE
[jira] [Comment Edited] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15494580#comment-15494580
]
Edward Ribeiro edited comment on ZOOKEEPER-2579 at 9/16/16 1:27 PM:
{quote}
I guess it would be reasonable to say that the tests that I wrote are more like
integration tests while the tests that you attached are true unit tests. I
guess it could be argued that most of the tests in ZooKeeperServerMainTest are
really integration tests.
{quote}
Yup, I agree.
{quote}
It would be possible to include both types of test instead of needing to
choose. What do you think?
{quote}
Sounds good to me. In fact, it's up to you leave the
{{FileTxnSnapLogTest.java}} or not. :) Let's see what the committers say, but I
am okay with either approach, at first.
*By the way, thanks for pointing out {{testWithoutAutoCreateDataLogDir}}
because it reminded me that it would be nice to include the timeout (i.e.,
{{@Test(timeout = 3)}}) in those kind of tests. Please, update your patch
accordingly. ;)*
Best regards,
was (Author: eribeiro):
{quote}
I guess it would be reasonable to say that the tests that I wrote are more like
integration tests while the tests that you attached are true unit tests. I
guess it could be argued that most of the tests in ZooKeeperServerMainTest are
really integration tests.
{quote}
Yup, I agree.
{quote}
It would be possible to include both types of test instead of needing to
choose. What do you think?
{quote}
Sounds good to me. In fact, it's up to you leave the
{{FileTxnSnapLogTest.java}} or not. :) Let's see what the committers say, but I
am okay with either approach, at first.
By the way, thanks for pointing out
{{ZooKeeperServerMainTest.testWithoutAutoCreateDataLogDir}} because it reminded
me that it would be nice to include the timeout (i.e., {{@Test(timeout =
3)}}) in those kind of tests.
Best regards,
> ZooKeeper server should verify that dataDir and snapDir are writeable before
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch,
> ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not
> writeable, the server does not fail until it actually tries to write there.
> It should fail when it starts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15494580#comment-15494580
]
Edward Ribeiro commented on ZOOKEEPER-2579:
---
{quote}
I guess it would be reasonable to say that the tests that I wrote are more like
integration tests while the tests that you attached are true unit tests. I
guess it could be argued that most of the tests in ZooKeeperServerMainTest are
really integration tests.
{quote}
Yup, I agree.
{quote}
It would be possible to include both types of test instead of needing to
choose. What do you think?
{quote}
Sounds good to me. In fact, it's up to you leave the
{{FileTxnSnapLogTest.java}} or not. :) Let's see what the committers say, but I
am okay with either approach, at first.
By the way, thanks for pointing out
{{ZooKeeperServerMainTest.testWithoutAutoCreateDataLogDir}} because it reminded
me that it would be nice to include the timeout (i.e., {{@Test(timeout =
3)}}) in those kind of tests.
Best regards,
> ZooKeeper server should verify that dataDir and snapDir are writeable before
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch,
> ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not
> writeable, the server does not fail until it actually tries to write there.
> It should fail when it starts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2439: -- Labels: acl (was: ) > The order of asynchronous setACL is not correct. > > > Key: ZOOKEEPER-2439 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 > Environment: Linux Ubuntu > Mac OS X >Reporter: Kazuaki Banzai >Assignee: Edward Ribeiro > Labels: acl > Attachments: ZOOKEEPER-2439.patch > > > Within a given client connection, the execution of commands on the ZooKeeper > server is always ordered, as both synchronous and asynchronous commands are > dispatched through queuePacket (directly or indirectly). > In other words, Zookeeper guarantees sequential consistency: updates from a > client will be applied in the order that they were sent. > However, the order of asynchronous setACL is not correct on Ubuntu. > When asynchronous setACL is called BEFORE another API is called, asynchronous > setACL is applied AFTER another API. > For example, if a client calls > (1) asynchronous setACL to remove all permissions of node "/" and > (2) synchronous create to create node "/a", > synchronous create should fail, but it succeeds on Ubuntu. > (We can see all permissions of node "/" are removed when the client calls > getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL > between (1) and (2), the synchronous case works correctly but the > asynchronous case still produces the bug.) > The attached unit test reproduces this scenario. It fails on Linux Ubuntu but > succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test > sometimes fails as well but only rarely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2439) The order of asynchronous setACL is not correct.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro reassigned ZOOKEEPER-2439: - Assignee: Edward Ribeiro > The order of asynchronous setACL is not correct. > > > Key: ZOOKEEPER-2439 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2439 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 > Environment: Linux Ubuntu > Mac OS X >Reporter: Kazuaki Banzai >Assignee: Edward Ribeiro > Labels: acl > Attachments: ZOOKEEPER-2439.patch > > > Within a given client connection, the execution of commands on the ZooKeeper > server is always ordered, as both synchronous and asynchronous commands are > dispatched through queuePacket (directly or indirectly). > In other words, Zookeeper guarantees sequential consistency: updates from a > client will be applied in the order that they were sent. > However, the order of asynchronous setACL is not correct on Ubuntu. > When asynchronous setACL is called BEFORE another API is called, asynchronous > setACL is applied AFTER another API. > For example, if a client calls > (1) asynchronous setACL to remove all permissions of node "/" and > (2) synchronous create to create node "/a", > synchronous create should fail, but it succeeds on Ubuntu. > (We can see all permissions of node "/" are removed when the client calls > getACL to node "/" after (2), so (1) is applied AFTER (2). If we call getACL > between (1) and (2), the synchronous case works correctly but the > asynchronous case still produces the bug.) > The attached unit test reproduces this scenario. It fails on Linux Ubuntu but > succeeds on Mac OS X. If used on a heavily loaded server on Mac OS, the test > sometimes fails as well but only rarely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2496) When inside a transaction, some exceptions do not have path information set.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490356#comment-15490356 ] Edward Ribeiro commented on ZOOKEEPER-2496: --- Hey [~kazuakibanzai], could you please confirm if this issue is not a duplicate of https://issues.apache.org/jira/browse/ZOOKEEPER-2276 ? Thanks > When inside a transaction, some exceptions do not have path information set. > > > Key: ZOOKEEPER-2496 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2496 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.8, 3.5.1 >Reporter: Kazuaki Banzai > Attachments: transactionException.patch > > > If a client tries to execute some illegal operations inside a transaction, > ZooKeeper throws an exception. > Some exceptions such as NodeExistsException should have a path to indicate > where the exception occurred. > ZooKeeper clients can get the path by calling method getPath. > However, this method returns null if the exception occurs inside a > transaction. > For example, when a client calls create /a and create /a in a transaction, > ZooKeeper throws NodeExistsException but getPath returns null. > In normal operation (outside transactions), the path information is set > correctly. > The patch only shows this bug occurs with NoNode exception and NodeExists > exception, > but this bug seems to occur with any exception which needs a path information: > When an error occurred in a transaction, ZooKeeper creates an ErrorResult > instance to represent error result. > However, the ErrorResult class doesn't have a field for a path where an error > occurred(See src/java/main/org/apache/zookeeper/OpResult.java for more > details). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2579) ZooKeeper server should verify that dataDir and snapDir are writeable before starting
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2579:
--
Attachment: FileTxnSnapLogTest.java
Hey [~abrahamfine],
Nice patch. We badly deserve to exercise as much of the {{FileTxnSnapLog}} as
possible. It has been in the root of some annoying bugs that impact its
reliability. Thanks! :)
By the way, are you really sure you want to incur the burden of starting up a
ZK instance to test an exception, using a brittle test assertion (if I
understood correctly the test will pass if the server doesn't start up on time,
right?), when you can just write a simpler unit test to exercise this specific
part? See my attachment for ideas of how you can test your patch.
Cheers!
> ZooKeeper server should verify that dataDir and snapDir are writeable before
> starting
> -
>
> Key: ZOOKEEPER-2579
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2579
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Abraham Fine
>Assignee: Abraham Fine
> Fix For: 3.4.10, 3.5.3
>
> Attachments: FileTxnSnapLogTest.java, ZOOKEEPER-2579.patch,
> ZOOKEEPER-2579_3.4.patch
>
>
> If the directories specified for the dataDir or the snapDir are not
> writeable, the server does not fail until it actually tries to write there.
> It should fail when it starts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488628#comment-15488628
]
Edward Ribeiro commented on ZOOKEEPER-2572:
---
My central question is: besides the possible resource leak that Michael pointed
out, what's the right way of dealing with being unable to truncate the log
file? Return false if unable to truncate the file in the while loop? To catch
the exception in {{raf.setLength(pos);}} and set a flag to false? Let any error
bubble up and remove the {{boolean truncated = }} from the calling methods?
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.4.10, 3.5.3
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488593#comment-15488593
]
Edward Ribeiro edited comment on ZOOKEEPER-2572 at 9/13/16 10:11 PM:
-
Hey [~hanm], really good catch! :D
/cc [~fpj], [~breed], [~rakesh_r]
While studying this piece of code, I have seen a curious fact:
*{{FileTxnLog.truncate}} never returns false*. It's either throws IOException
or returns {{true}}.
But then it's call hierarchy eventually calls {{ZkDatabase.truncateLog}} as
below (my comments are in upper case below):
{code}
public boolean truncateLog(long zxid) throws IOException {
clear();
// truncate the log
boolean truncated = snapLog.truncateLog(zxid);
// IT WILL NEVER ENTER IN THIS IF
if (!truncated) {
return false;
}
loadDataBase();
return true;
}
{code}
And the method above is called by {{Learner.syncWithLeader}}, again with a
snippet below that will never be called, plus getting out of the
{{syncWithLeader}} middway.
{code}
boolean truncated=zk.getZKDatabase().truncateLog(qp.getZxid());
// AGAIN, NEVER CAN WILL BE TRUE
if (!truncated) {
// not able to truncate the log
LOG.error("Not able to truncate the log "
+ Long.toHexString(qp.getZxid()));
System.exit(13);
}
{code}
Does it make sense what I am saying?
was (Author: eribeiro):
Hey [~hanm], really good catch! :D
/cc [~fpj], [~breed], [~rakesh_r]
While studying this piece of code, I have seen a curious fact:
*{{FileTxnLog.truncate}} never returns false*. It's either throws IOException
or returns {{true}}.
But then it's call hierarchy eventually calls {{ZkDatabase.truncateLog}} as
below (my comments are in upper case below):
{code}
public boolean truncateLog(long zxid) throws IOException {
clear();
// truncate the log
boolean truncated = snapLog.truncateLog(zxid);
// IT WILL NEVER ENTER IN THIS IF
if (!truncated) {
return false;
}
loadDataBase();
return true;
}
{code}
And the method above is called by {{Learner.syncWithLeader}}, again with a
snippet below that will never be called, plus getting out of the
{{syncWithLeader}} middway.
{quote}
boolean truncated=zk.getZKDatabase().truncateLog(qp.getZxid());
// AGAIN, NEVER CAN WILL BE TRUE
if (!truncated) {
// not able to truncate the log
LOG.error("Not able to truncate the log "
+ Long.toHexString(qp.getZxid()));
System.exit(13);
}
{quote}
Does it make sense what I am saying?
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.4.10, 3.5.3
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488593#comment-15488593
]
Edward Ribeiro edited comment on ZOOKEEPER-2572 at 9/13/16 10:09 PM:
-
Hey [~hanm], really good catch! :D
/cc [~fpj], [~breed], [~rakesh_r]
While studying this piece of code, I have seen a curious fact:
*{{FileTxnLog.truncate}} never returns false*. It's either throws IOException
or returns {{true}}.
But then it's call hierarchy eventually calls {{ZkDatabase.truncateLog}} as
below (my comments are in upper case below):
{code}
public boolean truncateLog(long zxid) throws IOException {
clear();
// truncate the log
boolean truncated = snapLog.truncateLog(zxid);
// IT WILL NEVER ENTER IN THIS IF
if (!truncated) {
return false;
}
loadDataBase();
return true;
}
{code}
And the method above is called by {{Learner.syncWithLeader}}, again with a
snippet below that will never be called, plus getting out of the
{{syncWithLeader}} middway.
{quote}
boolean truncated=zk.getZKDatabase().truncateLog(qp.getZxid());
// AGAIN, NEVER CAN WILL BE TRUE
if (!truncated) {
// not able to truncate the log
LOG.error("Not able to truncate the log "
+ Long.toHexString(qp.getZxid()));
System.exit(13);
}
{quote}
Does it make sense what I am saying?
was (Author: eribeiro):
Hey [~hanm], really good catch! :D
/cc [~fpj], [~breed], [~rakesh_r]
While studying this piece of code, I have seen a curious fact: *this method
never returns false*. It's either IOException or {{true}}.
But then it's call hierarchy eventually calls {{ZkDatabase.truncateLog}} as
below (my comments are in upper case below):
{code}
public boolean truncateLog(long zxid) throws IOException {
clear();
// truncate the log
boolean truncated = snapLog.truncateLog(zxid);
// IT WILL NEVER ENTER IN THIS IF
if (!truncated) {
return false;
}
loadDataBase();
return true;
}
{code}
And the method above is called by {{Learner.syncWithLeader}}, again with a
snippet below that will never be called, plus getting out of the
{{syncWithLeader}} middway.
{quote}
boolean truncated=zk.getZKDatabase().truncateLog(qp.getZxid());
// AGAIN, NEVER CAN WILL BE TRUE
if (!truncated) {
// not able to truncate the log
LOG.error("Not able to truncate the log "
+ Long.toHexString(qp.getZxid()));
System.exit(13);
}
{quote}
Does it make sense what I am saying?
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.4.10, 3.5.3
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2572) Potential resource leak in FileTxnLog.truncate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488593#comment-15488593
]
Edward Ribeiro commented on ZOOKEEPER-2572:
---
Hey [~hanm], really good catch! :D
/cc [~fpj], [~breed], [~rakesh_r]
While studying this piece of code, I have seen a curious fact: *this method
never returns false*. It's either IOException or {{true}}.
But then it's call hierarchy eventually calls {{ZkDatabase.truncateLog}} as
below (my comments are in upper case below):
{code}
public boolean truncateLog(long zxid) throws IOException {
clear();
// truncate the log
boolean truncated = snapLog.truncateLog(zxid);
// IT WILL NEVER ENTER IN THIS IF
if (!truncated) {
return false;
}
loadDataBase();
return true;
}
{code}
And the method above is called by {{Learner.syncWithLeader}}, again with a
snippet below that will never be called, plus getting out of the
{{syncWithLeader}} middway.
{quote}
boolean truncated=zk.getZKDatabase().truncateLog(qp.getZxid());
// AGAIN, NEVER CAN WILL BE TRUE
if (!truncated) {
// not able to truncate the log
LOG.error("Not able to truncate the log "
+ Long.toHexString(qp.getZxid()));
System.exit(13);
}
{quote}
Does it make sense what I am saying?
> Potential resource leak in FileTxnLog.truncate
> --
>
> Key: ZOOKEEPER-2572
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2572
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.9, 3.5.2
>Reporter: Michael Han
> Fix For: 3.4.10, 3.5.3
>
>
> In FileTxnLog.truncate, we have:
> {code}
> public boolean truncate(long zxid) throws IOException {
> FileTxnIterator itr = null;
> try {
> itr = new FileTxnIterator(this.logDir, zxid);
> PositionInputStream input = itr.inputStream;
> if(input == null) {
> throw new IOException("No log files found to truncate! This
> could " +
> "happen if you still have snapshots from an old setup
> or " +
> "log files were deleted accidentally or dataLogDir
> was changed in zoo.cfg.");
> }
> long pos = input.getPosition();
> // now, truncate at the current position
> RandomAccessFile raf=new RandomAccessFile(itr.logFile,"rw");
> raf.setLength(pos);
> raf.close();
> while(itr.goToNextLog()) {
> if (!itr.logFile.delete()) {
> LOG.warn("Unable to truncate {}", itr.logFile);
> }
> }
> } finally {
> close(itr);
> }
> return true;
> }
> {code}
> {{raf}} here can be potentially in a state of not closed after leaving the
> method, if there is an (IO) exception thrown from setLength.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2465: -- Attachment: ZOOKEEPER-2465.2.patch [~hanm], you right! Uploading a new version of the patch now. > 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-2431) C client documentation improvement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2431: -- Labels: documentation (was: ) > C client documentation improvement > -- > > Key: ZOOKEEPER-2431 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2431 > Project: ZooKeeper > Issue Type: Improvement > Components: c client, documentation >Affects Versions: 3.4.8 >Reporter: Michael Han >Assignee: Michael Han > Labels: documentation > Fix For: 3.5.3 > > > The existing documentation of C client in Programmer's Guide is incomplete > and there are many TBD sections. We should improve the documentation by > completing all the TBD sections and add more sample code to demonstrate C > client API usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-671) Lot of [tbd]-s ( missing links ? ) in the overview page
[ https://issues.apache.org/jira/browse/ZOOKEEPER-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-671: - Labels: documentation (was: ) > Lot of [tbd]-s ( missing links ? ) in the overview page > - > > Key: ZOOKEEPER-671 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-671 > Project: ZooKeeper > Issue Type: Improvement > Components: documentation >Reporter: Karthik K > Labels: documentation > > The zk documentation at - > http://hadoop.apache.org/zookeeper/docs/r3.2.2/zookeeperOver.html , has quite > a number of [tbd] in place of missing links in it. > It would be nice to see those links fixed to add value to the documentation / > overview. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-815) fill in "TBD"s in overview doc
[ https://issues.apache.org/jira/browse/ZOOKEEPER-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-815: - Labels: documentation (was: ) > fill in "TBD"s in overview doc > -- > > Key: ZOOKEEPER-815 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-815 > Project: ZooKeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.3.1 >Reporter: Patrick Hunt >Priority: Minor > Labels: documentation > Fix For: 3.6.0 > > > Funny: "Ephemeral nodes are useful when you want to implement [tbd]." there > are a few others in that doc that are should really be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2465:
--
Attachment: ZOOKEEPER-2465.patch
Hi [~cnauroth],
As the issue is marked as {{Blocker}}, I am providing a patch to fix the dates.
_But, as Ben Reed rightfully commented, we should discuss on the mailing list
and with legal oriented people if it is really required to update the copyright
each year._
Cheers! :)
PS: the patch applies to trunk and branch-3.5, it's was generated with
{{--no-prefix}}, btw.
> 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.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] [Issue Comment Deleted] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2465: -- Comment: was deleted (was: Yeah, totally agree with you both. Also, as [~fpj] pointed out, it's very important to clean up and complete the docs. I am voluteering to help on this task, btw.) > 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 > > > 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] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487827#comment-15487827 ] Edward Ribeiro commented on ZOOKEEPER-2465: --- I propose to address the current year on this issue (it's a quite trivial patch) and then proceed to a more long term discussion on legal-discuss or similar channels. Wdyt? > 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 > > > 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] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487821#comment-15487821 ] Edward Ribeiro commented on ZOOKEEPER-2465: --- Yeah, totally agree with you both. Also, as [~fpj] pointed out, it's very important to clean up and complete the docs. I am voluteering to help on this task, btw. > 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 > > > 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] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15487822#comment-15487822 ] Edward Ribeiro commented on ZOOKEEPER-2465: --- Yeah, totally agree with you both. Also, as [~fpj] pointed out, it's very important to clean up and complete the docs. I am voluteering to help on this task, btw. > 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 > > > 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] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15485659#comment-15485659 ] Edward Ribeiro commented on ZOOKEEPER-2465: --- Yes, Michael, I was going to investigate this approach, that is, to get current year as part of the doc generation. But my first dig into Forrest left me with the same opinion as yours: quite limited in terms of programmability (didn't finish to look it tough). IMHO, we should open a new ticket to look for alternatives for doc gen. Maybe Sphinx or something else? > 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 > > > 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] [Commented] (ZOOKEEPER-2465) Documentation copyright notice is out of date.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15485431#comment-15485431 ] Edward Ribeiro commented on ZOOKEEPER-2465: --- Cool, [~breed]! :) I have no problem leaving it 2008 nor legal knowledge to make a definitive statement. I am okay with closing this issue tough. Anybody else agrees? > 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 > > > 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] [Comment Edited] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471276#comment-15471276 ] Edward Ribeiro edited comment on ZOOKEEPER-2552 at 9/12/16 6:20 PM: The patch is up, thanks. *UPDATE:* Hi [~rakeshr], I have double checked the issues reported last week and my patch removed the 'Open' and 'Patch Available' ones. Feel free to apply it to branch-4.5 when you find appropriate. Cheers! was (Author: eribeiro): The patch is up, thanks. > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Edward Ribeiro > Fix For: 3.4.10 > > Attachments: ZOOKEEPER-2552.patch, closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro reassigned ZOOKEEPER-2521: - Assignee: Edward Ribeiro > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Assignee: Edward Ribeiro >Priority: Minor > Attachments: ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2521) space should be truncated while reading password for keystore/truststore which is required to configure while SSL enabled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2521: -- Attachment: ZOOKEEPER-2521.patch Patch attached, [~rakeshsingh]. > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled > - > > Key: ZOOKEEPER-2521 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2521 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Rakesh Kumar Singh >Priority: Minor > Attachments: ZOOKEEPER-2521.patch > > > space should be truncated while reading password for keystore/truststore > which is required to configure while SSL enabled. > As of now if we configure the password with any heading/trailing space, the > zookeeper server will fail to start. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2547) IP ACL is not working with NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15477514#comment-15477514
]
Edward Ribeiro commented on ZOOKEEPER-2547:
---
{quote}
I think the diamond operator is only for saving few key strokes. is there any
other advantage?
{quote}
To modernize the code base. ;) But that's okay to leave as it is, no problem at
all.
{quote}
We are running the server on 127.0.0.1. The result of
InetAddress.getLocalHost().getAddress().toString() will be different in
different environment. So can not use
InetAddress.getLocalHost().getAddress().toString()
{quote}
Yup, you right. In fact, I should have suggested to use
{{InetAddress.getLoopbackAddress().getAddress().toString()}}, but, again, we
can leave this as it is.
{quote}
The added test case is testing both Netty and NIO.
NIO passes before and after the fix
Netty fails before the fix but passed after the fix.
{quote}
Yes, I saw that. My original recommendation was to add another tests to check
if the znode creation *fails* when a different IP address is set up in the ACL
(say, "192.0.0.1"). The current test checks if the loopback address can create
(a "positive" test), but *maybe* a negative test can be worth. I don't know.
> IP ACL is not working with NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-2547
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2547
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2547-01.patch
>
>
> IP based ACL is not working with NettyServerCnxnFactory.
> Scenario:
> 1) Configure serverCnxnFactory=
> org.apache.zookeeper.server.NettyServerCnxnFactory and start ZooKeeper server
> 2) Create a znode "/n" with ACL(ZooDefs.Perms.ALL, new Id("ip",
> "127.0.0.1/8")
> 3) Create child node /n/n1. Child node creation fails.
> But the same above scenario works with NIOServerCnxnFactory
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: ZOOKEEPER-2557-3.4.patch
ZOOKEEPER-2557.patch
Hi [~phunt], [~cnauroth],
My previous patches for this issue failed because, even tough {{trunk}} and
{{branch-3.5}} are in sync wrt {{.gitignore}}, {{branch-3.4}} had some
additions lacking on {{trunk/branch-3.5}} *and vice-versa*, as we can see below:
{code}
eribeiro@WP0091:~/IdeaProjects/zookeeper(trunk)$ git diff trunk..branch-3.4 --
.gitignore
diff --git a/.gitignore b/.gitignore
index 2926274..2428fad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,18 +1,22 @@
.classpath
.eclipse/
-.idea/
.project
.revision/
.settings/
build/
-out/
-*.iml
-src/c/core.*
-src/c/TEST-*.txt
-src/c/*.la
-src/c/*.lo
-src/c/*.o
src/c/generated/
src/java/generated/
src/java/lib/ant-eclipse-*
src/java/lib/ivy-*
+src/c/Makefile.in
+src/c/aclocal.m4
+src/c/autom4te.cache/
+src/c/compile
+src/c/config.guess
+src/c/config.h.in
+src/c/config.sub
+src/c/configure
+src/c/depcomp
+src/c/install-sh
+src/c/ltmain.sh
+src/c/missing
{code}
A straightforward approach would be to apply the patch to {{branch-3.4}} and
merge it upward, but I've found *a lot of conflicts with other files* when
going 3.4->3.5->trunk (mostly pdf files, but some Java sources too).
So, *I created two patches: one for {{trunk/branch-3.5}} (ZOOKEEPER-2557.patch)
and other for {{branch-3.4}} (ZOOKEEPER-2557-3.4.patch) *. Once committed,
.gitignore will be consistent across the branches (we can even do git
cherry-pick from branch-3.5 to trunk).
Still we may have some headaches with merging upwards with other files, but
this is a issue for another patch, right?
*Please, take a look to see if the final .gitignore makes sense, particularly
wrt the C files it ignores.* Thanks in advance.
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2557-3.4.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: (was: ZOOKEEPER-2557.patch)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: (was: ZOOKEEPER-2557.2.patch)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: (was: ZOOKEEPER-2557-3.4.patch)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: (was: ZOOKEEPER-2557-3.5.patch)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474512#comment-15474512
]
Edward Ribeiro commented on ZOOKEEPER-2517:
---
Nice points, Arshad. LGTM.
> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch,
> ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
> clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
> ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
> clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
> )
> );{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2517:
--
Comment: was deleted
(was: It has been updated. LGTM.)
> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch,
> ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
> clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
> ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
> clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
> )
> );{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474508#comment-15474508
]
Edward Ribeiro commented on ZOOKEEPER-2517:
---
It has been updated. LGTM.
> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch,
> ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
> clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
> ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
> clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
> )
> );{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15474509#comment-15474509
]
Edward Ribeiro commented on ZOOKEEPER-2517:
---
It has been updated. LGTM.
> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch,
> ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
> clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
> ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
> clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
> )
> );{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471695#comment-15471695
]
Edward Ribeiro commented on ZOOKEEPER-2557:
---
Chris and Patrick, totally agree with the superset approach across
3.4->3.5->trunk. Gonna work on that and check inconsistences before uploading
the new patch asap. Thanks for the feedback! :)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2557-3.4.patch, ZOOKEEPER-2557-3.5.patch,
> ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: ZOOKEEPER-2557-3.5.patch
ZOOKEEPER-2557-3.4.patch
I am attaching additional patches for 3.4 and 3.5 because they were conflicting
with trunk (ZOOKEEPER-2557.2.patch) and had additional files that are absent
from gitignore at trunk.
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2557-3.4.patch, ZOOKEEPER-2557-3.5.patch,
> ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Comment: was deleted
(was: Forgot --no-prefix.)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: ZOOKEEPER-2557.2.patch
Forgot --no-prefix.
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: (was: ZOOKEEPER-2557.2.patch)
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: ZOOKEEPER-2557.2.patch
[~phunt], I have double checked svn ignore file list. Most are already in the
patch, but I have included a few that are not. Please, let me know if there is
any absence. I will check again later today.
[~cnauroth], I have included the orig and rej files as requested.
Currently the patch applies to trunk only, but the procedure in this project is
to apply to the early affected version and merge it to the newer ones? If so,
which one? Thanks!
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.2.patch, ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2552: -- Attachment: ZOOKEEPER-2552.patch The patch is up, thanks. > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Edward Ribeiro > Fix For: 3.4.10 > > Attachments: ZOOKEEPER-2552.patch, closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15471193#comment-15471193
]
Edward Ribeiro commented on ZOOKEEPER-2557:
---
Thanks for the feedback! :) I am gonna incorporate both suggestions of you
(nope, I didn't check SVN ignore list, but gonna do this now). If you come up
with any other inclusion/exclusion I am more than happy to change it.
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Labels: easyfix (was: )
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Labels: easyfix (was: )
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Labels: easyfix
> Attachments: ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Affects Version/s: 3.4.8
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.4.8
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Attachments: ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2557:
--
Attachment: ZOOKEEPER-2557.patch
Besides some well known extensions (.swp, .bak), I have included more files
extensions from https://github.com/github/gitignore. My only concern here is if
.class, .ear, .war and .jar files should be included or not in the gitignore
file.
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
> Attachments: ZOOKEEPER-2557.patch
>
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro reassigned ZOOKEEPER-2557:
-
Assignee: Edward Ribeiro
> Update gitignore to account for other file extensions
> -
>
> Key: ZOOKEEPER-2557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Trivial
>
> We are in the process of moving from subversion to git, but I have seen that
> the current ZK's {{gitignore}} doesn't account for many spurious types of
> files (e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse,
> Intellij and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2557) Update gitignore to account for other file extensions
Edward Ribeiro created ZOOKEEPER-2557:
-
Summary: Update gitignore to account for other file extensions
Key: ZOOKEEPER-2557
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2557
Project: ZooKeeper
Issue Type: Improvement
Reporter: Edward Ribeiro
Priority: Trivial
We are in the process of moving from subversion to git, but I have seen that
the current ZK's {{gitignore}} doesn't account for many spurious types of files
(e.g., *.swp, *.tmp) as well as other files created by IDEs (Eclipse, Intellij
and NetBeans), among other file extensions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro reassigned ZOOKEEPER-2552: - Assignee: Edward Ribeiro (was: Rakesh R) > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Edward Ribeiro > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467718#comment-15467718 ] Edward Ribeiro commented on ZOOKEEPER-2552: --- Thanks for suggestion [~rakeshr]. It's highly appreciated, I will take note. Maybe we can add this piece of info to the docs at https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute ? Excuse me for the dumb question, but I thought it would be just a matter of --alter-- (removing) the fix version of the affected versions. What files would this patch touch? I am okay with preparing a patch for it, btw. > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2552: -- Comment: was deleted (was: Thanks for suggestion [~rakeshr]. It's highly appreciated, I will take note. Maybe we can add this piece of info to the docs at https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute ? Excuse me for the dumb question, but I thought it would be just a matter of --alter-- (removing) the fix version of the affected versions. What files would this patch touch? I am okay with preparing a patch for it, btw.) > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467718#comment-15467718 ] Edward Ribeiro edited comment on ZOOKEEPER-2552 at 9/6/16 3:41 PM: --- Thanks for suggestion [~rakeshr]. It's highly appreciated, I will take note. Maybe we can add this piece of info to the docs at https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute ? Excuse me for the dumb question, but I thought it would be just a matter of --alter-- (removing) the fix version of the affected JIRAs. What files would this patch touch? I am okay with preparing a patch for it, btw. was (Author: eribeiro): Thanks for suggestion [~rakeshr]. It's highly appreciated, I will take note. Maybe we can add this piece of info to the docs at https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute ? Excuse me for the dumb question, but I thought it would be just a matter of --alter-- (removing) the fix version of the affected versions. What files would this patch touch? I am okay with preparing a patch for it, btw. > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15467719#comment-15467719 ] Edward Ribeiro commented on ZOOKEEPER-2552: --- Thanks for suggestion [~rakeshr]. It's highly appreciated, I will take note. Maybe we can add this piece of info to the docs at https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute ? Excuse me for the dumb question, but I thought it would be just a matter of --alter-- (removing) the fix version of the affected versions. What files would this patch touch? I am okay with preparing a patch for it, btw. > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465012#comment-15465012
]
Edward Ribeiro edited comment on ZOOKEEPER-2552 at 9/6/16 2:01 PM:
---
I added a {{sleep}} time between url fetches so that I *hopefully* don't
flood/DoS the JIRA server.
*UPDATE:* running my naive script, these are the issues it identified (had to
restart at least three times because connection was reset by peer, probably
some anti-DoS feature so I included a snippet to bypass the URLs already
visited).
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2391
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2468
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2512
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2236
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2327
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2313
*UPDATE 2:* pushed my issues (ZOOKEEPER-2512 & ZOOKEEPER-2313) to 3.5.3. ;)
was (Author: eribeiro):
I added a {{sleep}} time between url fetches so that I *hopefully* don't
flood/DoS the JIRA server.
*UPDATE:* running my naive script, these are the issues it identified (had to
restart at least three times because connection was reset by peer, probably
some anti-DoS feature so I included a snippet to bypass the URLs already
visited).
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2391
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2468
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2512
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2236
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2327
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2313
> Revisit release note doc and remove the items which are not related to the
> released version
> ---
>
> Key: ZOOKEEPER-2552
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.4.10
>
> Attachments: closed.py
>
>
> Couple of issues listed on http://zookeeper.apache.org/
> doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For
> example, issues were wrongly marked as "3.4.8" fix version in jira and has
> caused the trouble.
> This jira to cross check all the jira issues present in the release note and
> check the correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2512) Allow Jetty dependency to use HTTPS and Basic Auth
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2512: -- Fix Version/s: (was: 3.5.1) (was: 3.4.8) (was: 3.5.0) 3.5.3 > Allow Jetty dependency to use HTTPS and Basic Auth > -- > > Key: ZOOKEEPER-2512 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2512 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.5.2 >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro > Labels: security > Fix For: 3.5.3 > > > If ZOOKEEPER-2489 gets committed then it would be nice to allow more flexible > configuration of https and basic authentication to JettyAdminServer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2280) NettyServerCnxnFactory doesn't honor maxClientCnxns param
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2280: -- Fix Version/s: (was: 3.5.1) 3.5.3 > NettyServerCnxnFactory doesn't honor maxClientCnxns param > - > > Key: ZOOKEEPER-2280 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2280 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.6, 3.5.0, 3.5.1 >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro > Fix For: 3.5.3 > > Attachments: ZOOKEEPER-2280.2.patch, ZOOKEEPER-2280.patch > > > Even though NettyServerCnxnFactory has maxClientCnxns (default to 60) it > doesn't enforce this limit in the code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2313) Refactor ZooKeeperServerBean and its subclasses (LeaderBean, ObserverBean, FollowerBean)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2313: -- Fix Version/s: (was: 3.4.6) 3.5.3 > Refactor ZooKeeperServerBean and its subclasses (LeaderBean, ObserverBean, > FollowerBean) > > > Key: ZOOKEEPER-2313 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2313 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.4.6 >Reporter: Edward Ribeiro >Assignee: Edward Ribeiro >Priority: Minor > Fix For: 3.5.3 > > > Following the work on ZOOKEEPER-2142, the goal of this ticket is to add a new > constructor to ZooKeeperServerBean to pass the name as the parameter, so > classes that extend from ZooKeeperServerBean shouldn't need to implement > getName() method. Also, ObserverBean seems to be in the wrong package, it > should be under server.quorum rather than just server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2552: -- Attachment: (was: closed.py) > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2552: -- Attachment: (was: closed.py) > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edward Ribeiro updated ZOOKEEPER-2552: -- Attachment: closed.py > Revisit release note doc and remove the items which are not related to the > released version > --- > > Key: ZOOKEEPER-2552 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552 > Project: ZooKeeper > Issue Type: Bug >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.10 > > Attachments: closed.py > > > Couple of issues listed on http://zookeeper.apache.org/ > doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For > example, issues were wrongly marked as "3.4.8" fix version in jira and has > caused the trouble. > This jira to cross check all the jira issues present in the release note and > check the correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15465012#comment-15465012
]
Edward Ribeiro edited comment on ZOOKEEPER-2552 at 9/5/16 2:43 PM:
---
I added a {{sleep}} time between url fetches so that I *hopefully* don't
flood/DoS the JIRA server.
*UPDATE:* running my naive script, these are the issues it identified (had to
restart at least three times because connection was reset by peer, probably
some anti-DoS feature so I included a snippet to bypass the URLs already
visited).
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2391
Patch Available https://issues.apache.org/jira/browse/ZOOKEEPER-2468
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2512
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2236
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2327
Open https://issues.apache.org/jira/browse/ZOOKEEPER-2313
was (Author: eribeiro):
I added a {{sleep}} time between url fetches so that I *hopefully* don't
flood/DoS the JIRA server.
> Revisit release note doc and remove the items which are not related to the
> released version
> ---
>
> Key: ZOOKEEPER-2552
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.4.10
>
> Attachments: closed.py, closed.py
>
>
> Couple of issues listed on http://zookeeper.apache.org/
> doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For
> example, issues were wrongly marked as "3.4.8" fix version in jira and has
> caused the trouble.
> This jira to cross check all the jira issues present in the release note and
> check the correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2552) Revisit release note doc and remove the items which are not related to the released version
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Edward Ribeiro updated ZOOKEEPER-2552:
--
Attachment: closed.py
I added a {{sleep}} time between url fetches so that I *hopefully* don't
flood/DoS the JIRA server.
> Revisit release note doc and remove the items which are not related to the
> released version
> ---
>
> Key: ZOOKEEPER-2552
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2552
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Rakesh R
>Assignee: Rakesh R
> Fix For: 3.4.10
>
> Attachments: closed.py, closed.py
>
>
> Couple of issues listed on http://zookeeper.apache.org/
> doc/r3.4.9/releasenotes.html that are either 'Open' or 'Patch available'. For
> example, issues were wrongly marked as "3.4.8" fix version in jira and has
> caused the trouble.
> This jira to cross check all the jira issues present in the release note and
> check the correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
