[
https://issues.apache.org/jira/browse/KAFKA-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551566#comment-16551566
]
ASF GitHub Bot commented on KAFKA-7177:
---------------------------------------
lindong28 closed pull request #5384: KAFKA-7177: Update 2.0 documentation to
reflect changed quota behaviors by KIP-219
URL: https://github.com/apache/kafka/pull/5384
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/docs/design.html b/docs/design.html
index 69d1941effd..bdc7e637ea9 100644
--- a/docs/design.html
+++ b/docs/design.html
@@ -610,10 +610,12 @@ <h4><a id="design_quotasenforcement"
href="#design_quotasenforcement">Enforcemen
having a fixed cluster wide bandwidth per client because that would
require a mechanism to share client quota usage among all the brokers. This can
be harder to get right than the quota implementation itself!
</p>
<p>
- How does a broker react when it detects a quota violation? In our
solution, the broker does not return an error rather it attempts to slow down a
client exceeding its quota.
- It computes the amount of delay needed to bring a guilty client under
its quota and delays the response for that time. This approach keeps the quota
violation transparent to clients
- (outside of client-side metrics). This also keeps them from having to
implement any special backoff and retry behavior which can get tricky. In fact,
bad client behavior (retry without backoff)
- can exacerbate the very problem quotas are trying to solve.
+ How does a broker react when it detects a quota violation? In our
solution, the broker first computes the amount of delay needed to bring the
violating client under its quota
+ and returns a response with the delay immediately. In case of a fetch
request, the response will not contain any data. Then, the broker mutes the
channel to the client,
+ not to process requests from the client anymore, until the delay is
over. Upon receiving a response with a non-zero delay duration, the Kafka
client will also refrain from
+ sending further requests to the broker during the delay. Therefore,
requests from a throttled client are effectively blocked from both sides.
+ Even with older client implementations that do not respect the delay
response from the broker, the back pressure applied by the broker via muting
its socket channel
+ can still handle the throttling of badly behaving clients. Those
clients who sent further requests to the throttled channel will receive
responses only after the delay is over.
</p>
<p>
Byte-rate and thread utilization are measured over multiple small windows
(e.g. 30 windows of 1 second each) in order to detect and correct quota
violations quickly. Typically, having large measurement windows
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Update 2.0 documentation to reflect changed quota behaviors by KIP-219
> -----------------------------------------------------------------------
>
> Key: KAFKA-7177
> URL: https://issues.apache.org/jira/browse/KAFKA-7177
> Project: Kafka
> Issue Type: Task
> Components: documentation
> Reporter: Jon Lee
> Assignee: Jon Lee
> Priority: Major
> Fix For: 2.1.0
>
>
> KIP-219 changed the way quota violation is communicated between clients and
> brokers. Documentation should be updated accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
