[jira] [Commented] (ZOOKEEPER-3418) Improve quorum throughput through eager ACL checks of requests on local servers

["Fangmin Lv (JIRA)" <ji...@apache.org>]

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

Fangmin Lv commented on ZOOKEEPER-3418:
---------------------------------------

[~hanm] we're thinking of optimizing other throughput of not proposing and quorum voting on error txns like version conflict, node not exist during setData, etc.

Current plan is to having the leader prepare the txn and send the error response directly to the server who forwarded that request if there is error, and not propose to other learners. This will introduce more changes including protocol changes, which is more complexity than check locally. But it goes through leader and provides better guarantee of the order, and maximize the possibility of reducing unnecessary txns.

What's your thought on this?

> 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
>          Time Spent: 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.3#76005)