date:20170802

[jira] [Commented] (ZOOKEEPER-2355) Ephemeral node is never deleted if follower fails while reading the proposal packet

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user arshadmohammad commented on the issue:

https://github.com/apache/zookeeper/pull/304
  
LGTM +1


> Ephemeral node is never deleted if follower fails while reading the proposal 
> packet
> ---
>
> Key: ZOOKEEPER-2355
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2355
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum, server
>Affects Versions: 3.4.8, 3.4.9, 3.4.10, 3.5.1, 3.5.2, 3.5.3
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Critical
> Attachments: ZOOKEEPER-2355-01.patch, ZOOKEEPER-2355-02.patch, 
> ZOOKEEPER-2355-03.patch, ZOOKEEPER-2355-04.patch, ZOOKEEPER-2355-05.patch
>
>
> ZooKeeper ephemeral node is never deleted if follower fail while reading the 
> proposal packet
> The scenario is as follows:
> # Configure three node ZooKeeper cluster, lets say nodes are A, B and C, 
> start all, assume A is leader, B and C are follower
> # Connect to any of the server and create ephemeral node /e1
> # Close the session, ephemeral node /e1 will go for deletion
> # While receiving delete proposal make Follower B to fail with 
> {{SocketTimeoutException}}. This we need to do to reproduce the scenario 
> otherwise in production environment it happens because of network fault.
> # Remove the fault, just check that faulted Follower is now connected with 
> quorum
> # Connect to any of the server, create the same ephemeral node /e1, created 
> is success.
> # Close the session,  ephemeral node /e1 will go for deletion
> # {color:red}/e1 is not deleted from the faulted Follower B, It should have 
> been deleted as it was again created with another session{color}
> # {color:green}/e1 is deleted from Leader A and other Follower C{color}



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

[GitHub] zookeeper issue #304: ZOOKEEPER-2355: Ephemeral node is never deleted if fol...

2017-08-02 Thread arshadmohammad

Github user arshadmohammad commented on the issue:

https://github.com/apache/zookeeper/pull/304
  
LGTM +1


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

Failed: ZOOKEEPER- PreCommit Build #918

2017-08-02 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/918/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 72.09 MB...]
 [exec] +0 tests included.  The patch appears to be a documentation 
patch that doesn't require tests.
 [exec] 
 [exec] -1 javadoc.  The javadoc tool appears to have generated 8 
warning messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 3.0.1) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/918//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/918//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/918//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Comment added.
 [exec] 02f1b8f3634861276d291933936a987711b4f422 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] mv: 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 and 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 are the same file

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/build.xml:1643:
 exec returned: 1

Total time: 19 minutes 51 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2853
Putting comment on the pull request
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on ZOOKEEPER-2853:
--

-1 overall.  GitHub Pull Request  Build
  

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

+0 tests included.  The patch appears to be a documentation patch that 
doesn't require tests.

-1 javadoc.  The javadoc tool appears to have generated 8 warning messages.

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

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

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

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

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

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

This message is automatically generated.

> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

Failed: ZOOKEEPER- PreCommit Build #919

2017-08-02 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/919/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 3.21 KB...]
 [exec] Pull request title: [ZOOKEEPER-2852] Read snapshotSizeFactor from 
system property
 [exec]   % Total% Received % Xferd  Average Speed   TimeTime 
Time  CurrentDefect number: ZOOKEEPER-2852
 [exec] 
 [exec] - Parsed args, going to checkout -
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Testing patch for pull request 321.
 [exec] 
==
 [exec] 
==
 [exec]  Dload  Upload   Total   Spent
Left  Speed
 [exec] 
 [exec] 
 [exec] 
 [exec] 
 [exec]   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0100   1410   1410 0746  0 --:--:-- --:--:-- 
--:--:--   750
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec]  Pre-build trunk to verify trunk stability and javac warnings
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] /home/jenkins/tools/ant/apache-ant-1.9.9/bin/ant  
-Djavac.args=-Xlint -Xmaxwarns 1000 
-Djava5.home=/home/jenkins/tools/java5/latest 
-Dforrest.home=/home/jenkins/tools/forrest/latest -DZookeeperPatchProcess= 
clean tar > 
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build@2/patchprocess/trunkJavacWarnings.txt
 2>&1
 [exec] Trunk compilation is broken?
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec]   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0  0 00  32270 0   7588  0 --:--:-- --:--:-- 
--:--:-- 
3151k/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build@2/src/java/test/bin/test-github-pr.sh:
 line 153: 26965 Killed  $ANT_HOME/bin/ant -Djavac.args="-Xlint 
-Xmaxwarns 1000" -Djava5.home=${JAVA5_HOME} -Dforrest.home=${FORREST_HOME} 
-DZookeeperPatchProcess= clean tar > $PATCH_DIR/trunkJavacWarnings.txt 2>&1
 [exec] mv: 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build@2/patchprocess'
 and 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build@2/patchprocess'
 are the same file

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build@2/build.xml:1643:
 exec returned: 1

Total time: 29 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2852
Putting comment on the pull request
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



###
## FAILED TESTS (if any) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-2846) Leader follower sync with on disk txns can possibly leads to data inconsistency

2017-08-02 Thread Fangmin Lv (JIRA)


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

Fangmin Lv commented on ZOOKEEPER-2846:
---

[~hanm] ZOOKEEPER-2099 is a subset of the issue I reported in this Jira, the 
bug of this Jira is introduced by ZOOKEEPER-1413, which is using on disk txn 
sync to reduce sync time.  

The issue I reported in ZOOKEEPER-2845 is a totally different one, it's 
introduced in ZOOKEEPER-2678, which is used to reduce unavailable time during 
leader election by retain the ZKDatabase, but it could lead to data 
inconsistency.

> Leader follower sync with on disk txns can possibly leads to data 
> inconsistency
> ---
>
> Key: ZOOKEEPER-2846
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2846
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.10, 3.5.3, 3.6.0
>Reporter: Fangmin Lv
>Priority: Critical
>
> On disk txn sync could cause data inconsistency if the current leader just 
> had a snap sync before it became leader, and then having diff sync with its 
> followers may synced the txns gap on disk. Here is scenario: 
> Let's say S0 - S3 are followers, and S4 is leader at the beginning:
> 1. Stop S2 and send one more request
> 2. Stop S3 and send more requests to the quorum to let S3 have a snap sync 
> with S4 when it started up
> 3. Stop S4 and S3 became the new leader
> 4. Start S2 and had a diff sync with S3, now there are gaps in S2
> Attached the test case to verify the issue. Currently, there is no efficient 
> way to check the gap in txn files is a real gap or due to Epoch change. We 
> need to add that support, but before that, it would be safer to disable the 
> on disk txn leader-follower sync.
> Another two scenarios which could cause the same issue:
> (Scenario 1) Server A, B, C, A is leader, the others are followers:
>   1). A synced to disk, but the other 2 restarted before receiving the 
> proposal
>   2). B and C formed quorum, B is leader, and committed some requests
>   3). A looking again, and sync with B, B won't able to trunc A but send snap 
> instead, and leaves the extra txn in A's txn file
>   4). A became new leader, and someone else has a diff sync with A it will 
> have the extra txn 
> (Scenario 2) Diff sync with committed txn, will only apply to data tree but 
> not on disk txn file, which will also leave hole in it and lead to data 
> inconsistency issue when syncing with learners.



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

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

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/136
  
This patch requires a rebase.


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



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

[GitHub] zookeeper issue #136: [ZOOKEEPER-1416] Persistent Recursive Watch

2017-08-02 Thread hanm

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/136
  
This patch requires a rebase.


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

[jira] [Updated] (ZOOKEEPER-2843) auth_to_local should support reading rules from a file

2017-08-02 Thread Michael Han (JIRA)


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

Michael Han updated ZOOKEEPER-2843:
---
Component/s: server
 kerberos

> auth_to_local should support reading rules from a file
> --
>
> Key: ZOOKEEPER-2843
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2843
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: kerberos, server
>Affects Versions: 3.4.10, 3.5.3
>Reporter: Lionel Cons
>Assignee: Lionel Cons
> Attachments: ZOOKEEPER-2843.patch
>
>
> The current handling of {{zookeeper.security.auth_to_local}} in 
> {{KerberosName.java}} only supports rules given directly as property value.
> These rules must therefore be given on the command line and:
> * must be escaped properly to avoid shell expansion
> * are visible in the {{ps}} output
> It would be much better to put these rules in a file and pass the file path 
> as the property value. We would then use something like 
> {{-Dzookeeper.security.auth_to_local=file:/etc/zookeeper/rules}}.
> Note that using the {{file:}} prefix allows keeping backward compatibility.



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

[jira] [Assigned] (ZOOKEEPER-2843) auth_to_local should support reading rules from a file

2017-08-02 Thread Michael Han (JIRA)


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

Michael Han reassigned ZOOKEEPER-2843:
--

Assignee: Lionel Cons

> auth_to_local should support reading rules from a file
> --
>
> Key: ZOOKEEPER-2843
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2843
> Project: ZooKeeper
>  Issue Type: Improvement
>Affects Versions: 3.4.10, 3.5.3
>Reporter: Lionel Cons
>Assignee: Lionel Cons
> Attachments: ZOOKEEPER-2843.patch
>
>
> The current handling of {{zookeeper.security.auth_to_local}} in 
> {{KerberosName.java}} only supports rules given directly as property value.
> These rules must therefore be given on the command line and:
> * must be escaped properly to avoid shell expansion
> * are visible in the {{ps}} output
> It would be much better to put these rules in a file and pass the file path 
> as the property value. We would then use something like 
> {{-Dzookeeper.security.auth_to_local=file:/etc/zookeeper/rules}}.
> Note that using the {{file:}} prefix allows keeping backward compatibility.



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

[jira] [Updated] (ZOOKEEPER-2843) auth_to_local should support reading rules from a file

2017-08-02 Thread Michael Han (JIRA)


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

Michael Han updated ZOOKEEPER-2843:
---
Affects Version/s: 3.4.10
   3.5.3

> auth_to_local should support reading rules from a file
> --
>
> Key: ZOOKEEPER-2843
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2843
> Project: ZooKeeper
>  Issue Type: Improvement
>Affects Versions: 3.4.10, 3.5.3
>Reporter: Lionel Cons
>Assignee: Lionel Cons
> Attachments: ZOOKEEPER-2843.patch
>
>
> The current handling of {{zookeeper.security.auth_to_local}} in 
> {{KerberosName.java}} only supports rules given directly as property value.
> These rules must therefore be given on the command line and:
> * must be escaped properly to avoid shell expansion
> * are visible in the {{ps}} output
> It would be much better to put these rules in a file and pass the file path 
> as the property value. We would then use something like 
> {{-Dzookeeper.security.auth_to_local=file:/etc/zookeeper/rules}}.
> Note that using the {{file:}} prefix allows keeping backward compatibility.



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

[jira] [Commented] (ZOOKEEPER-2843) auth_to_local should support reading rules from a file

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/324
  
I think we can just make zookeeper.security.auth_to_local a configuration 
option in zoo.cfg, so it could be loaded either from zoo.cfg (the static 
configuration file), or read from system property if available, rather than 
loading it from a random on disk file. This also conforms to what Hadoop is 
doing in terms of reading auth_to_local (Hadoop stores it in core-site.xml).


> auth_to_local should support reading rules from a file
> --
>
> Key: ZOOKEEPER-2843
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2843
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Lionel Cons
> Attachments: ZOOKEEPER-2843.patch
>
>
> The current handling of {{zookeeper.security.auth_to_local}} in 
> {{KerberosName.java}} only supports rules given directly as property value.
> These rules must therefore be given on the command line and:
> * must be escaped properly to avoid shell expansion
> * are visible in the {{ps}} output
> It would be much better to put these rules in a file and pass the file path 
> as the property value. We would then use something like 
> {{-Dzookeeper.security.auth_to_local=file:/etc/zookeeper/rules}}.
> Note that using the {{file:}} prefix allows keeping backward compatibility.



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

[GitHub] zookeeper issue #324: ZOOKEEPER-2843: auth_to_local now supports reading rul...

2017-08-02 Thread hanm

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/324
  
I think we can just make zookeeper.security.auth_to_local a configuration 
option in zoo.cfg, so it could be loaded either from zoo.cfg (the static 
configuration file), or read from system property if available, rather than 
loading it from a random on disk file. This also conforms to what Hadoop is 
doing in terms of reading auth_to_local (Hadoop stores it in core-site.xml).


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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131053635
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I would recommend make the early return changes here as the changes to be 
made is small and they are not hard to review. When we say "do it separately" 
in the context of zk, it probably implies "never" 


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread hanm

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131053635
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I would recommend make the early return changes here as the changes to be 
made is small and they are not hard to review. When we say "do it separately" 
in the context of zk, it probably implies "never" 


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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052685
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -118,7 +118,7 @@
 fsyncWarningThresholdMS = fsyncWarningThreshold;
 }
 
-long lastZxidSeen;
+long lastMaxZxidSeen;
--- End diff --

oh, last minute change left the issue here, was thinking of lastMaxZxidSeen 
will be more accurate, but thought a bit more and lastZxidSeen should be Ok 
too, so changed it back, forgot to change here.


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052928
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I prefer return early too, I didn't change it as it's not related with this 
diff, and I'd like to make it with minimum change. I can update it here too if 
you guys prefer.


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052814
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

@maoling my vim editor will remove the tailing space automatically, that's 
why there is so many changes, I think it's better to format it without tailing 
space.


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread lvfangmin

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052814
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

@maoling my vim editor will remove the tailing space automatically, that's 
why there is so many changes, I think it's better to format it without tailing 
space.


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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread lvfangmin

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052928
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I prefer return early too, I didn't change it as it's not related with this 
diff, and I'd like to make it with minimum change. I can update it here too if 
you guys prefer.


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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread lvfangmin

Github user lvfangmin commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131052685
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -118,7 +118,7 @@
 fsyncWarningThresholdMS = fsyncWarningThreshold;
 }
 
-long lastZxidSeen;
+long lastMaxZxidSeen;
--- End diff --

oh, last minute change left the issue here, was thinking of lastMaxZxidSeen 
will be more accurate, but thought a bit more and lastZxidSeen should be Ok 
too, so changed it back, forgot to change here.


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

[jira] [Commented] (ZOOKEEPER-2846) Leader follower sync with on disk txns can possibly leads to data inconsistency

2017-08-02 Thread Michael Han (JIRA)


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

Michael Han commented on ZOOKEEPER-2846:


ZOOKEEPER-2099 sounds similar to this?

Also, I am wondering what caused the bug. Is this bug existing since the 
feature's introduction by ZOOKEEPER-1413, or is it a regression caused by, for 
example ZOOKEEPER-2678 (which was mentioned in ZOOKEEPER-2845)?

> Leader follower sync with on disk txns can possibly leads to data 
> inconsistency
> ---
>
> Key: ZOOKEEPER-2846
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2846
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.10, 3.5.3, 3.6.0
>Reporter: Fangmin Lv
>Priority: Critical
>
> On disk txn sync could cause data inconsistency if the current leader just 
> had a snap sync before it became leader, and then having diff sync with its 
> followers may synced the txns gap on disk. Here is scenario: 
> Let's say S0 - S3 are followers, and S4 is leader at the beginning:
> 1. Stop S2 and send one more request
> 2. Stop S3 and send more requests to the quorum to let S3 have a snap sync 
> with S4 when it started up
> 3. Stop S4 and S3 became the new leader
> 4. Start S2 and had a diff sync with S3, now there are gaps in S2
> Attached the test case to verify the issue. Currently, there is no efficient 
> way to check the gap in txn files is a real gap or due to Epoch change. We 
> need to add that support, but before that, it would be safer to disable the 
> on disk txn leader-follower sync.
> Another two scenarios which could cause the same issue:
> (Scenario 1) Server A, B, C, A is leader, the others are followers:
>   1). A synced to disk, but the other 2 restarted before receiving the 
> proposal
>   2). B and C formed quorum, B is leader, and committed some requests
>   3). A looking again, and sync with B, B won't able to trunc A but send snap 
> instead, and leaves the extra txn in A's txn file
>   4). A became new leader, and someone else has a diff sync with A it will 
> have the extra txn 
> (Scenario 2) Diff sync with committed txn, will only apply to data tree but 
> not on disk txn file, which will also leave hole in it and lead to data 
> inconsistency issue when syncing with learners.



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

[jira] [Commented] (ZOOKEEPER-2852) Snapshot size factor is not read from system property

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/321#discussion_r131051673
  
--- Diff: src/java/main/org/apache/zookeeper/server/ZKDatabase.java ---
@@ -98,6 +98,16 @@ public ZKDatabase(FileTxnSnapLog snapLog) {
 dataTree = new DataTree();
 sessionsWithTimeouts = new ConcurrentHashMap();
 this.snapLog = snapLog;
+
+// Read system property
+String value = System.getProperty(SNAPSHOT_SIZE_FACTOR, "0.33");
+try {
+snapshotSizeFactor = Double.parseDouble(value);
+} catch (NumberFormatException e) {
+LOG.error("Error parsing " + SNAPSHOT_SIZE_FACTOR
--- End diff --

Please use parameterized log messages.


> Snapshot size factor is not read from system property
> -
>
> Key: ZOOKEEPER-2852
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2852
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.3, 3.6.0
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>
> There is data inconsistency issue found when leader is using on disk txn 
> files to sync with learner: ZOOKEEPER-2846, tried to disable this feature by 
> setting zookeeper.snapshotSizeFactor system property, but found this system 
> property is not being read anywhere.



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

[GitHub] zookeeper pull request #321: [ZOOKEEPER-2852] Read snapshotSizeFactor from s...

2017-08-02 Thread hanm

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/321#discussion_r131051673
  
--- Diff: src/java/main/org/apache/zookeeper/server/ZKDatabase.java ---
@@ -98,6 +98,16 @@ public ZKDatabase(FileTxnSnapLog snapLog) {
 dataTree = new DataTree();
 sessionsWithTimeouts = new ConcurrentHashMap();
 this.snapLog = snapLog;
+
+// Read system property
+String value = System.getProperty(SNAPSHOT_SIZE_FACTOR, "0.33");
+try {
+snapshotSizeFactor = Double.parseDouble(value);
+} catch (NumberFormatException e) {
+LOG.error("Error parsing " + SNAPSHOT_SIZE_FACTOR
--- End diff --

Please use parameterized log messages.


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

[GitHub] zookeeper issue #325: Fix typos in zookeeperAdmin.html

2017-08-02 Thread hanm

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/325
  
Doc change should be done on doc source file instead of on the html file 
directly - see my comment here:
https://github.com/apache/zookeeper/pull/275#issuecomment-307161978


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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131049471
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I like the suggestion here. Though ZK does not enforce such style, early 
exists is my preference for reasons documented here: 
https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
 Though this change can be done separately as it's not an existing stylish 
issue.

>> BTW,why do I see so many flaky changes?

Not sure about what flaky changes you are referring to? @maoling  


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread hanm

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131049471
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -199,14 +199,16 @@ public synchronized boolean append(TxnHeader hdr, 
Record txn)
 LOG.warn("Current zxid " + hdr.getZxid()
--- End diff --

I like the suggestion here. Though ZK does not enforce such style, early 
exists is my preference for reasons documented here: 
https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
 Though this change can be done separately as it's not an existing stylish 
issue.

>> BTW,why do I see so many flaky changes?

Not sure about what flaky changes you are referring to? @maoling  


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

[jira] [Commented] (ZOOKEEPER-2853) The lastZxidSeen in FileTxnLog.java is never being assigned

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131049142
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -118,7 +118,7 @@
 fsyncWarningThresholdMS = fsyncWarningThreshold;
 }
 
-long lastZxidSeen;
+long lastMaxZxidSeen;
--- End diff --

Yes this patch does not build @lvfangmin 


> The lastZxidSeen in FileTxnLog.java is never being assigned
> ---
>
> Key: ZOOKEEPER-2853
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2853
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Minor
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
>
> There is log in FileTxnLog#append to track the txn with smaller zxid than the 
> last seen, but the lastZxidSeen is never being assigned, so that log is not 
> printed when it's happened.



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

[GitHub] zookeeper pull request #322: [ZOOKEEPER-2853] Update lastZxidSeen in FileTxn...

2017-08-02 Thread hanm

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/322#discussion_r131049142
  
--- Diff: 
src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java ---
@@ -118,7 +118,7 @@
 fsyncWarningThresholdMS = fsyncWarningThreshold;
 }
 
-long lastZxidSeen;
+long lastMaxZxidSeen;
--- End diff --

Yes this patch does not build @lvfangmin 


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

[jira] [Commented] (ZOOKEEPER-1669) Operations to server will be timed-out while thousands of sessions expired same time

2017-08-02 Thread ASF GitHub Bot (JIRA)


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

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

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/312#discussion_r131049051
  
--- Diff: src/java/main/org/apache/zookeeper/server/NIOServerCnxn.java ---
@@ -1001,25 +1010,14 @@ public String toString() {
 @Override
 public void close() {
 synchronized(factory.cnxns){
--- End diff --

@CheneySun Please let me know if what you think regarding my comment about 
removing the excessive synchronization here. 


> Operations to server will be timed-out while thousands of sessions expired 
> same time
> 
>
> Key: ZOOKEEPER-1669
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1669
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.5
>Reporter: tokoot
>Assignee: Cheney Sun
>  Labels: performance
>
> If there are thousands of clients, and most of them disconnect with server 
> same time(client restarted or servers partitioned with clients), the server 
> will busy to close those "connections" and become unavailable. The problem is 
> in following:
>   private void closeSessionWithoutWakeup(long sessionId) {
>   HashSet cnxns;
>   synchronized (this.cnxns) {
>   cnxns = (HashSet)this.cnxns.clone();  // other 
> thread will block because of here
>   }
>   ...
>   }
> A real world example that demonstrated this problem (Kudos to [~sun.cheney]):
> {noformat}
> The issue is raised while tens thousands of clients try to reconnect 
> ZooKeeper service. 
> Actually, we came across the issue during maintaining our HBase cluster, 
> which used a 5-server ZooKeeper cluster. 
> The HBase cluster was composed of many many regionservers (in thousand order 
> of magnitude), 
> and connected by tens thousands of clients to do massive reads/writes. 
> Because the r/w throughput is very high, ZooKeeper zxid increased quickly as 
> well. 
> Basically, each two or three weeks, Zookeeper would make leader relection 
> triggered by the zxid roll over. 
> The leader relection will cause the clients(HBase regionservers and HBase 
> clients) disconnected 
> and reconnected with Zookeeper servers in the mean time, and try to renew the 
> sessions.
> In current implementation of session renew, NIOServerCnxnFactory will clone 
> all the connections at first 
> in order to avoid race condition in multi-threads and go iterate the cloned 
> connection set one by one to 
> find the related session to renew. It's very time consuming. In our case 
> (described above), 
> it caused many region servers can't successfully renew session before session 
> timeout, 
> and eventually the HBase cluster lose these region servers and affect the 
> HBase stability.
> The change is to make refactoring to the close session logic and introduce a 
> ConcurrentHashMap 
> to store session id and connection map relation, which is a thread-safe data 
> structure 
> and eliminate the necessary to clone the connection set at first.
> {noformat}



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

[GitHub] zookeeper pull request #312: ZOOKEEPER-1669: Operations to server will be ti...

2017-08-02 Thread hanm

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/312#discussion_r131049051
  
--- Diff: src/java/main/org/apache/zookeeper/server/NIOServerCnxn.java ---
@@ -1001,25 +1010,14 @@ public String toString() {
 @Override
 public void close() {
 synchronized(factory.cnxns){
--- End diff --

@CheneySun Please let me know if what you think regarding my comment about 
removing the excessive synchronization here. 


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

Failed: ZOOKEEPER- PreCommit Build #917

2017-08-02 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/917/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 71.76 MB...]
 [exec] +0 tests included.  The patch appears to be a documentation 
patch that doesn't require tests.
 [exec] 
 [exec] -1 javadoc.  The javadoc tool appears to have generated 8 
warning messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 3.0.1) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/917//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/917//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/917//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Error: No value specified for option "issue"
 [exec] b0b473f78392822a0e417b672978f3eaac37853b logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] mv: 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 and 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 are the same file

BUILD FAILED
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/build.xml:1643:
 exec returned: 1

Total time: 17 minutes 34 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-1355
Putting comment on the pull request
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



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

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

2017-08-02 Thread Apache Jenkins Server

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 63.98 MB...]
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2017-08-02 11:55:29,473 [myid:127.0.0.1:27380] - INFO  
[main-SendThread(127.0.0.1:27380):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27380. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2017-08-02 11:55:29,474 [myid:127.0.0.1:27380] - WARN  
[main-SendThread(127.0.0.1:27380):ClientCnxn$SendThread@1235] - Session 
0x1051c3856dc for server 127.0.0.1/127.0.0.1:27380, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2017-08-02 11:55:29,611 [myid:127.0.0.1:27509] - INFO  
[main-SendThread(127.0.0.1:27509):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27509. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2017-08-02 11:55:29,612 [myid:127.0.0.1:27509] - WARN  
[main-SendThread(127.0.0.1:27509):ClientCnxn$SendThread@1235] - Session 
0x3051c3b5825 for server 127.0.0.1/127.0.0.1:27509, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2017-08-02 11:55:29,740 [myid:] - INFO  [ProcessThread(sid:0 
cport:27626)::PrepRequestProcessor@614] - Processed session termination for 
sessionid: 0x1051c3e7300
[junit] 2017-08-02 11:55:29,744 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port27626,name1=Connections,name2=127.0.0.1,name3=0x1051c3e7300]
[junit] 2017-08-02 11:55:29,744 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1051c3e7300
[junit] 2017-08-02 11:55:29,744 [myid:] - INFO  [main:ZooKeeper@1332] - 
Session: 0x1051c3e7300 closed
[junit] 2017-08-02 11:55:29,744 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 165082
[junit] 2017-08-02 11:55:29,744 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 863
[junit] 2017-08-02 11:55:29,745 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2017-08-02 11:55:29,745 [myid:] - INFO  [main:ClientBase@601] - 
tearDown starting
[junit] 2017-08-02 11:55:29,745 [myid:] - INFO  [main:ClientBase@571] - 
STOPPING server
[junit] 2017-08-02 11:55:29,745 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:27626
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  [main:ZooKeeperServer@541] 
- shutting down
[junit] 2017-08-02 11:55:29,747 [myid:] - ERROR [main:ZooKeeperServer@505] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  
[main:PrepRequestProcessor@1008] - Shutting down
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  [ProcessThread(sid:0 
cport:27626)::PrepRequestProcessor@155] - PrepRequestProcessor exited loop!
[junit] 2017-08-02 11:55:29,747 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2017-08-02 11:55:29,748 [myid:] - INFO  
[main:FinalRequestProcessor@481] - shutdown of request processor complete
[junit] 2017-08-02 11:55:29,748 [myid:] -

[GitHub] zookeeper pull request #325: Fix typos in zookeeperAdmin.html

2017-08-02 Thread makubi

GitHub user makubi opened a pull request:

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

Fix typos in zookeeperAdmin.html



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

$ git pull https://github.com/makubi/zookeeper doc-zookeeperAdmin-typos

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

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

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

This closes #325


commit c988f4f71ac5fb6e72090f61bb705b19e55a9cc9
Author: Mathias Kub 
Date:   2017-08-02T11:47:09Z

Fix typos in zookeeperAdmin.html




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

ZooKeeper_branch35_jdk7 - Build # 1065 - Still Failing

2017-08-02 Thread Apache Jenkins Server

See https://builds.apache.org/job/ZooKeeper_branch35_jdk7/1065/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 69.62 MB...]
[junit] 2017-08-02 08:48:38,999 [myid:] - INFO  [main:ClientBase@586] - 
tearDown starting
[junit] 2017-08-02 08:48:38,999 [myid:] - INFO  [main:ClientBase@556] - 
STOPPING server
[junit] 2017-08-02 08:48:38,999 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:27626
[junit] 2017-08-02 08:48:39,005 [myid:] - INFO  [main:ZooKeeperServer@541] 
- shutting down
[junit] 2017-08-02 08:48:39,005 [myid:] - ERROR [main:ZooKeeperServer@505] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2017-08-02 08:48:39,005 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2017-08-02 08:48:39,005 [myid:] - INFO  
[main:PrepRequestProcessor@1005] - Shutting down
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  [ProcessThread(sid:0 
cport:27626)::PrepRequestProcessor@155] - PrepRequestProcessor exited loop!
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  
[main:FinalRequestProcessor@481] - shutdown of request processor complete
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port27626,name1=InMemoryDataTree]
[junit] 2017-08-02 08:48:39,006 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port27626]
[junit] 2017-08-02 08:48:39,007 [myid:] - INFO  
[main:FourLetterWordMain@87] - connecting to 127.0.0.1 27626
[junit] 2017-08-02 08:48:39,007 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2017-08-02 08:48:39,016 [myid:] - INFO  [main:ClientBase@611] - 
fdcount after test is: 7163 at start it was 7163
[junit] 2017-08-02 08:48:39,016 [myid:] - INFO  [main:ZKTestCase$1@68] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2017-08-02 08:48:39,017 [myid:] - INFO  [main:ZKTestCase$1@63] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 103, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
424.76 sec, Thread: 7, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2017-08-02 08:48:39,287 [myid:127.0.0.1:27503] - INFO  
[main-SendThread(127.0.0.1:27503):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27503. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2017-08-02 08:48:39,288 [myid:127.0.0.1:27503] - WARN  
[main-SendThread(127.0.0.1:27503):ClientCnxn$SendThread@1235] - Session 
0x105cd5147d5 for server 127.0.0.1/127.0.0.1:27503, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2017-08-02 08:48:39,370 [myid:127.0.0.1:27509] - INFO  
[main-SendThread(127.0.0.1:27509):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27509. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2017-08-02 08:48:39,370 [myid:127.0.0.1:27509] - WARN  
[main-SendThread(127.0.0.1:27509):ClientCnxn$SendThread@1235] - Session 
0x305cd5147d7 for server 127.0.0.1/127.0.0.1:27509, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:744)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2017-08-02 08:48:39,374 [myid:127.0.0.1:27444] - INFO  
[main-SendThread(127.0.0.1:27444):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:27444. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2017-08-02 08:48:39,375 [myid:127.0.0.1:27444] - WARN  
[main-SendThread(127.0.0.1:27444):ClientCnxn$SendThread@1235] - Session 
0x105cd4eaf52 for server 127.0.0.1/127.0.0.1:27444, unexpected error,

Success: ZOOKEEPER- PreCommit Build #916

2017-08-02 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/916/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 34.75 MB...]
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +0 tests included.  The patch appears to be a documentation 
patch that doesn't require tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 3.0.1) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/916//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/916//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/916//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Comment added.
 [exec] 2a7ed3a6e15985f3c71e207d37ac7166afee1342 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] mv: 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 and 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 are the same file

BUILD SUCCESSFUL
Total time: 35 minutes 11 seconds
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Description set: ZOOKEEPER-2843
Putting comment on the pull request
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Success
Sending email for trigger: Success
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



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

[jira] [Commented] (ZOOKEEPER-2843) auth_to_local should support reading rules from a file

2017-08-02 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on ZOOKEEPER-2843:
--

+1 overall.  GitHub Pull Request  Build
  

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

+0 tests included.  The patch appears to be a documentation patch that 
doesn't require tests.

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

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

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

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

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

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

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

This message is automatically generated.

> auth_to_local should support reading rules from a file
> --
>
> Key: ZOOKEEPER-2843
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2843
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: Lionel Cons
> Attachments: ZOOKEEPER-2843.patch
>
>
> The current handling of {{zookeeper.security.auth_to_local}} in 
> {{KerberosName.java}} only supports rules given directly as property value.
> These rules must therefore be given on the command line and:
> * must be escaped properly to avoid shell expansion
> * are visible in the {{ps}} output
> It would be much better to put these rules in a file and pass the file path 
> as the property value. We would then use something like 
> {{-Dzookeeper.security.auth_to_local=file:/etc/zookeeper/rules}}.
> Note that using the {{file:}} prefix allows keeping backward compatibility.



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

37 matches

Mail list logo