[jira] [Assigned] (ZOOKEEPER-3485) Measure reconfiguration time
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Han reassigned ZOOKEEPER-3485:
--
Assignee: Karolos Antoniadis
> Measure reconfiguration time
>
>
> Key: ZOOKEEPER-3485
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3485
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.5.5
>Reporter: Karolos Antoniadis
>Assignee: Karolos Antoniadis
>Priority: Minor
>
> This issue is created after some initial discussion in the _dev_ mailing list
> (subject "Leader election logging during reconfiguration").
>
> There does not seem to be a good way to measure reconfiguration time in
> ZooKeeper. Additionally, reconfiguration time is mixed together with leader
> election time*.* For instance, during reconfiguration, ZooKeeper logs a
> {{LEADER ELECTION TOOK}} message even though no leader election might takes
> place.
>
> This can be reproduced by following these steps:
> 1) start a ZooKeeper cluster (e.g., 3 participants)
> 2) start a client that connects to some follower
> 3) perform a _reconfig_ operation that removes the leader from the cluster
>
> After the reconfiguration takes place, we can see that the log files of the
> remaining participants contain a "_LEADER ELECTION TOOK_" message. For
> example, a line that contains
> _2019-07-29 23:07:38,518 [myid:2] - INFO
> [QuorumPeer[myid=2](plain=0.0.0.0:2792)(secure=disabled):Follower@75] -
> FOLLOWING - LEADER ELECTION TOOK - 57 MS_
>
> However, no leader election took place, in the sense that no server went
> _LOOKING_ and then started voting and sending notifications to other
> participants as would be in a normal leader election. It seems, that before
> the _reconfig_ is committed, the participant that is going to be the next
> leader is already decided (see here:
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/Leader.java#L865]).
>
> *Goal* of this issue/improvement is to measure in a better and more accurate
> way the time it takes for a reconfiguration to complete, as well as, to
> clearly distinguish the measurement of reconfiguration versus leader election.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3485) Measure reconfiguration time
Karolos Antoniadis created ZOOKEEPER-3485:
-
Summary: Measure reconfiguration time
Key: ZOOKEEPER-3485
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3485
Project: ZooKeeper
Issue Type: Improvement
Affects Versions: 3.5.5
Reporter: Karolos Antoniadis
This issue is created after some initial discussion in the _dev_ mailing list
(subject "Leader election logging during reconfiguration").
There does not seem to be a good way to measure reconfiguration time in
ZooKeeper. Additionally, reconfiguration time is mixed together with leader
election time*.* For instance, during reconfiguration, ZooKeeper logs a
{{LEADER ELECTION TOOK}} message even though no leader election might takes
place.
This can be reproduced by following these steps:
1) start a ZooKeeper cluster (e.g., 3 participants)
2) start a client that connects to some follower
3) perform a _reconfig_ operation that removes the leader from the cluster
After the reconfiguration takes place, we can see that the log files of the
remaining participants contain a "_LEADER ELECTION TOOK_" message. For example,
a line that contains
_2019-07-29 23:07:38,518 [myid:2] - INFO
[QuorumPeer[myid=2](plain=0.0.0.0:2792)(secure=disabled):Follower@75] -
FOLLOWING - LEADER ELECTION TOOK - 57 MS_
However, no leader election took place, in the sense that no server went
_LOOKING_ and then started voting and sending notifications to other
participants as would be in a normal leader election. It seems, that before the
_reconfig_ is committed, the participant that is going to be the next leader is
already decided (see here:
[https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/Leader.java#L865]).
*Goal* of this issue/improvement is to measure in a better and more accurate
way the time it takes for a reconfiguration to complete, as well as, to clearly
distinguish the measurement of reconfiguration versus leader election.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (ZOOKEEPER-1636) c-client crash when zoo_amulti failed
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Han updated ZOOKEEPER-1636: --- Fix Version/s: 3.4.15 > c-client crash when zoo_amulti failed > -- > > Key: ZOOKEEPER-1636 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1636 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.3 >Reporter: Thawan Kooburat >Assignee: Michael K. Edwards >Priority: Critical > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5, 3.4.15 > > Attachments: ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch, > ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch, ZOOKEEPER-1636.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > deserialize_response for multi operation don't handle the case where the > server fail to send back response. (Eg. when multi packet is too large) > c-client will try to process completion of all sub-request as if the > operation is successful and will eventually cause SIGSEGV -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (ZOOKEEPER-3484) Improve the throughput by optimizing the synchronization around outstandingChanges
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yisong Yue updated ZOOKEEPER-3484:
--
Description: The "processRequest(Request request)" function in
FinalRequestProcessor.java synchronizes around `outstandingChanges` for all
requests now. However, this synchronization is unnecessary for read requests,
and skipping such synchronization for reads can improve the overall throughput
of the request processor pipeline. (was: The "processTxn(Request request)"
function in ZooKeeperServer.java ("entry point for FinalRequestProcessor.java")
is synchronized around `outstandingChanges` for all requests now. However, this
synchronization is unnecessary for read requests, and skipping such
synchronization for reads can improve the overall throughput of the request
processor pipeline.)
> Improve the throughput by optimizing the synchronization around
> outstandingChanges
> --
>
> Key: ZOOKEEPER-3484
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3484
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: Yisong Yue
>Assignee: Yisong Yue
>Priority: Major
> Fix For: 3.6.0
>
>
> The "processRequest(Request request)" function in FinalRequestProcessor.java
> synchronizes around `outstandingChanges` for all requests now. However, this
> synchronization is unnecessary for read requests, and skipping such
> synchronization for reads can improve the overall throughput of the request
> processor pipeline.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (ZOOKEEPER-3483) Flaky test: org.apache.zookeeper.server.util.RequestPathMetricsCollectorTest.testCollectStats
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Han updated ZOOKEEPER-3483:
---
Labels: flaky-test (was: )
> Flaky test:
> org.apache.zookeeper.server.util.RequestPathMetricsCollectorTest.testCollectStats
> -
>
> Key: ZOOKEEPER-3483
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3483
> Project: ZooKeeper
> Issue Type: Test
> Components: tests
>Affects Versions: 3.6.0
>Reporter: Michael Han
>Assignee: Michael Han
>Priority: Minor
> Labels: flaky-test
>
> Test
> org.apache.zookeeper.server.util.RequestPathMetricsCollectorTest.testCollectStats
> consistently pass on local dev environment but frequently failing on Jenkins
> pre-commit build.
> For now disable the test to unblock a couple of pull request acquiring a
> green build, before it's completely addressed.
> Error for reference:
> {code:java}
> Error Message
> expected:<845466> but was:<111>
> Stacktrace
> java.lang.AssertionError: expected:<845466> but was:<111>
> at
> org.apache.zookeeper.server.util.RequestPathMetricsCollectorTest.testCollectStats(RequestPathMetricsCollectorTest.java:248)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (ZOOKEEPER-3482) SASL (Kerberos) Authentication with SSL for clients and Quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Franke updated ZOOKEEPER-3482: --- Description: It seems that Kerberos authentication does not work for encrypted connections of clients and quorum. It seems that only X509 Authentication works. What I would have expected: ClientSecurePort is defined A keystore and truststore are deployed on the ZooKeeper servers Only a truststore is deployed with the client (to validate the CA of the server certificate) Client can authenticate with SASL (Kerberos) Similarly, it should work for the Quorum SSL connection. Is there a way to configure this in ZooKeeper? Note: Kerberos Authentication for SSL encrypted connection should be used instead of X509 authentication for this case and not in addition. However, if it only works in 3.5.5 in addition then I would be interested and willing to test it. was: It seems that Kerberos authentication does not work for encrypted connections of clients and quorum. It seems that only X509 Authentication works. What I would have expected: ClientSecurePort is defined A keystore and truststore are deployed on the ZooKeeper servers Only a truststore is deployed with the client (to validate the CA of the server certificate) Client can authenticate with SASL (Kerberos) Similarly for the Quorum SSL connection. Is there a way to configure this in ZooKeeper? Note: Kerberos Authentication for SSL encrypted connection should be used instead of X509 authentication for this case and not in addition. However, if it only works in 3.5.5 in addition then I would be interested and willing to test it. > SASL (Kerberos) Authentication with SSL for clients and Quorum > -- > > Key: ZOOKEEPER-3482 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3482 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.5 >Reporter: Jörn Franke >Priority: Major > > It seems that Kerberos authentication does not work for encrypted connections > of clients and quorum. It seems that only X509 Authentication works. > What I would have expected: > ClientSecurePort is defined > A keystore and truststore are deployed on the ZooKeeper servers > Only a truststore is deployed with the client (to validate the CA of the > server certificate) > Client can authenticate with SASL (Kerberos) > Similarly, it should work for the Quorum SSL connection. > Is there a way to configure this in ZooKeeper? > > Note: Kerberos Authentication for SSL encrypted connection should be used > instead of X509 authentication for this case and not in addition. However, if > it only works in 3.5.5 in addition then I would be interested and willing to > test it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (ZOOKEEPER-3482) SASL (Kerberos) Authentication with SSL for clients and Quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Franke updated ZOOKEEPER-3482: --- Description: It seems that Kerberos authentication does not work for encrypted connections of clients and quorum. It seems that only X509 Authentication works. What I would have expected: ClientSecurePort is defined A keystore and truststore are deployed on the ZooKeeper servers Only a truststore is deployed with the client (to validate the CA of the server certificate) Client can authenticate with SASL (Kerberos) Similarly for the Quorum SSL connection. Is there a way to configure this in ZooKeeper? Note: Kerberos Authentication for SSL encrypted connection should be used instead of X509 authentication for this case and not in addition. However, if it only works in 3.5.5 in addition then I would be interested and willing to test it. was: It seems that Kerberos authentication does not work for encrypted connections of clients and quorum. It seems that only X509 Authentication works. What I would have expected: ClientSecurePort is defined A keystore and truststore are deployed on the ZooKeeper servers Only a truststore is deployed with the client (to validate the CA of the server certificate) Client can authenticate with SASL (Kerberos) Similarly for the Quorum SSL connection. Is there a way to configure this in ZooKeeeper? > SASL (Kerberos) Authentication with SSL for clients and Quorum > -- > > Key: ZOOKEEPER-3482 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3482 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.5 >Reporter: Jörn Franke >Priority: Major > > It seems that Kerberos authentication does not work for encrypted connections > of clients and quorum. It seems that only X509 Authentication works. > What I would have expected: > ClientSecurePort is defined > A keystore and truststore are deployed on the ZooKeeper servers > Only a truststore is deployed with the client (to validate the CA of the > server certificate) > Client can authenticate with SASL (Kerberos) > Similarly for the Quorum SSL connection. > Is there a way to configure this in ZooKeeper? > > Note: Kerberos Authentication for SSL encrypted connection should be used > instead of X509 authentication for this case and not in addition. However, if > it only works in 3.5.5 in addition then I would be interested and willing to > test it. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3482) SASL (Kerberos) Authentication with SSL for clients and Quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16898268#comment-16898268 ] Jörn Franke commented on ZOOKEEPER-3482: Please note that some ZooKeeper Clients, e.g. Solr, do not seem to support X509 Authentication+ACLs, but only Digest and SASL (Kerberos). > SASL (Kerberos) Authentication with SSL for clients and Quorum > -- > > Key: ZOOKEEPER-3482 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3482 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.5 >Reporter: Jörn Franke >Priority: Major > > It seems that Kerberos authentication does not work for encrypted connections > of clients and quorum. It seems that only X509 Authentication works. > What I would have expected: > ClientSecurePort is defined > A keystore and truststore are deployed on the ZooKeeper servers > Only a truststore is deployed with the client (to validate the CA of the > server certificate) > Client can authenticate with SASL (Kerberos) > Similarly for the Quorum SSL connection. > Is there a way to configure this in ZooKeeeper? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (ZOOKEEPER-3482) SASL (Kerberos) Authentication with SSL for clients and Quorum
Jörn Franke created ZOOKEEPER-3482: -- Summary: SASL (Kerberos) Authentication with SSL for clients and Quorum Key: ZOOKEEPER-3482 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3482 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.5 Reporter: Jörn Franke It seems that Kerberos authentication does not work for encrypted connections of clients and quorum. It seems that only X509 Authentication works. What I would have expected: ClientSecurePort is defined A keystore and truststore are deployed on the ZooKeeper servers Only a truststore is deployed with the client (to validate the CA of the server certificate) Client can authenticate with SASL (Kerberos) Similarly for the Quorum SSL connection. Is there a way to configure this in ZooKeeeper? -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (ZOOKEEPER-3461) add a doc about the admin server command
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
maoling reassigned ZOOKEEPER-3461:
--
Assignee: maoling
> add a doc about the admin server command
>
>
> Key: ZOOKEEPER-3461
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3461
> Project: ZooKeeper
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.6.0
>Reporter: maoling
>Assignee: maoling
>Priority: Major
>
> {code:java}
>
> The AdminServer
> **New in 3.5.0:** The AdminServer is
> an embedded Jetty server that provides an HTTP interface to the four
> letter word commands. By default, the server is started on port 8080,
> and commands are issued by going to the URL "/commands/\[command name]",
> e.g., http://localhost:8080/commands/stat. The command response is
> returned as JSON. Unlike the original protocol, commands are not
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3418) Improve quorum throughput through eager ACL checks of requests on local servers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897905#comment-16897905 ] Hudson commented on ZOOKEEPER-3418: --- FAILURE: Integrated in Jenkins build ZooKeeper-trunk #641 (See [https://builds.apache.org/job/ZooKeeper-trunk/641/]) ZOOKEEPER-3418: Improve quorum throughput through eager ACL checks of (eolivelli: rev b2f5548bd5757edbf1887838a487a90523ed2b52) * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LeaderRequestProcessor.java * (edit) zookeeper-server/src/test/java/org/apache/zookeeper/server/PrepRequestProcessorMetricsTest.java * (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/FollowerRequestProcessor.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/EagerACLFilterTest.java * (edit) zookeeper-server/src/test/java/org/apache/zookeeper/test/QuorumBase.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/ObserverRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/DataTree.java > Improve quorum throughput through eager ACL checks of requests on local > servers > --- > > Key: ZOOKEEPER-3418 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3418 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Michael Han >Priority: Major > Labels: Twitter, pull-request-available > Fix For: 3.6.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Serving write requests that change the state of the system requires quorum > operations, and in some cases, the quorum operations can be avoided if the > requests are doomed to fail. ACL check failure is such a case. To optimize > for this case, we elevate the ACL check logic and perform eager ACL check on > local server (where the requests are received), and fail fast, before sending > the requests to leader. > As with any features, there is a feature flag that can control this feature > on, or off (default). This feature is also forward compatible in that for new > any new Op code (and some existing Op code we did not explicit check > against), they will pass the check and (potentially) fail on leader side, > instead of being prematurely filtered out on local server. > The end result is better throughput and stability of the quorum for certain > workloads. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3430) Observability improvement: provide top N read / write path queries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897904#comment-16897904 ] Hudson commented on ZOOKEEPER-3430: --- FAILURE: Integrated in Jenkins build ZooKeeper-trunk #641 (See [https://builds.apache.org/job/ZooKeeper-trunk/641/]) ZOOKEEPER-3430: Observability improvement: provide top N read / write (eolivelli: rev 6d636025d1c6a10840a27caee9e8933f1dbcbaf0) * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/Request.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java * (add) zookeeper-server/src/main/java/org/apache/zookeeper/server/util/RequestPathMetricsCollector.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/util/RequestPathMetricsCollectorTest.java > Observability improvement: provide top N read / write path queries > -- > > Key: ZOOKEEPER-3430 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3430 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Michael Han >Priority: Major > Labels: Twitter, pull-request-available > Fix For: 3.6.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > We would like to have a better understanding of the type of workloads hit ZK, > and one aspect of such understanding is to be able to answer queries of top N > read and top N write request path. Knowing the hot request paths will allow > us better optimize for such workloads, for example, enabling path specific > caching, or change the path structure (e.g. break a long path to hierarchical > paths). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3418) Improve quorum throughput through eager ACL checks of requests on local servers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897881#comment-16897881 ] Hudson commented on ZOOKEEPER-3418: --- FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #475 (See [https://builds.apache.org/job/Zookeeper-trunk-single-thread/475/]) ZOOKEEPER-3418: Improve quorum throughput through eager ACL checks of (eolivelli: rev b2f5548bd5757edbf1887838a487a90523ed2b52) * (edit) zookeeper-server/src/test/java/org/apache/zookeeper/server/PrepRequestProcessorMetricsTest.java * (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/FollowerRequestProcessor.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/EagerACLFilterTest.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/DataTree.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LeaderRequestProcessor.java * (edit) zookeeper-server/src/test/java/org/apache/zookeeper/test/QuorumBase.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/ObserverRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/PrepRequestProcessor.java > Improve quorum throughput through eager ACL checks of requests on local > servers > --- > > Key: ZOOKEEPER-3418 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3418 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Michael Han >Priority: Major > Labels: Twitter, pull-request-available > Fix For: 3.6.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Serving write requests that change the state of the system requires quorum > operations, and in some cases, the quorum operations can be avoided if the > requests are doomed to fail. ACL check failure is such a case. To optimize > for this case, we elevate the ACL check logic and perform eager ACL check on > local server (where the requests are received), and fail fast, before sending > the requests to leader. > As with any features, there is a feature flag that can control this feature > on, or off (default). This feature is also forward compatible in that for new > any new Op code (and some existing Op code we did not explicit check > against), they will pass the check and (potentially) fail on leader side, > instead of being prematurely filtered out on local server. > The end result is better throughput and stability of the quorum for certain > workloads. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3430) Observability improvement: provide top N read / write path queries
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897880#comment-16897880 ] Hudson commented on ZOOKEEPER-3430: --- FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #475 (See [https://builds.apache.org/job/Zookeeper-trunk-single-thread/475/]) ZOOKEEPER-3430: Observability improvement: provide top N read / write (eolivelli: rev 6d636025d1c6a10840a27caee9e8933f1dbcbaf0) * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java * (add) zookeeper-server/src/main/java/org/apache/zookeeper/server/util/RequestPathMetricsCollector.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/Request.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/util/RequestPathMetricsCollectorTest.java > Observability improvement: provide top N read / write path queries > -- > > Key: ZOOKEEPER-3430 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3430 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Michael Han >Priority: Major > Labels: Twitter, pull-request-available > Fix For: 3.6.0 > > Time Spent: 3h 40m > Remaining Estimate: 0h > > We would like to have a better understanding of the type of workloads hit ZK, > and one aspect of such understanding is to be able to answer queries of top N > read and top N write request path. Knowing the hot request paths will allow > us better optimize for such workloads, for example, enabling path specific > caching, or change the path structure (e.g. break a long path to hierarchical > paths). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ZOOKEEPER-3473) Improving successful TLS handshake throughput with concurrent control
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897828#comment-16897828 ] Hadoop QA commented on ZOOKEEPER-3473: -- -1 overall. GitHub Pull Request Build +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 5 new or modified 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 failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/4089//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/4089//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/4089//console This message is automatically generated. > Improving successful TLS handshake throughput with concurrent control > - > > Key: ZOOKEEPER-3473 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3473 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Fangmin Lv >Assignee: Fangmin Lv >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 50m > Remaining Estimate: 0h > > When there are lots of clients trying to re-establish sessions, there might > be lots of half finished handshake timed out, and those failed ones keep > reconnecting to another server and restarting the handshake from beginning > again, which caused herd effect. > > And the number of total ZK sessions could be supported within session timeout > are impacted a lot after enabling TLS. > > To improve the throughput, we added the TLS concurrent control to reduce the > herd effect, and from out benchmark this doubled the sessions we could > support within session timeout. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
