...

All other requests may be throttled if the rate exceeds the configured quota. All requests that may be throttled will have an additional field request_throttle_time_ms to indicate to the client that the request was throttled.The versions of these requests will be incremented. The existing field throttle_time_ms in produce/fetch responses will be retained to return byte-rate throttling times, while the new field returns request throttling time based on request processing time.

Fetch and produce requests will continue to be throttled based on byte rates and may also be throttled based on request handler thread utilization. Fetch requests used for replication will not be throttled based on request times since it is possible to configure replica.fetch.wait.max.ms and use the existing replication byte rate quotas to limit replication rate.

...

Two new metrics and corresponding sensors will be added to the broker for tracking request-time and throttle-time of each quota entity for the new quota type IOThread. These will be handled similar to the metrics and sensors for Produce/Fetch. A delay queue sensor with queue-size for the new quota type IOThread will also be added similar to the delay queue sensor for Produce/Fetch.

Clients will expose average and maximum request throttle time as JMX metrics similar to the current produce/fetch throttle time metrics.

All the metrics and sensors for request time throttling will be of similar format to the existing produce/fetch metrics and sensors for consistency, but with new group/name indicating the new quota type IOThread, keeping these separate from existing metrics/sensors.

Tools

kafka-configs.sh will be extended to support request quotas.  A new quota property will be added, which can be applied to <client-id>, <user> or <user, client-id>:

...

Produce and fetch byte rate quotas will continue to be applied as they are today. Request processing time throttling will be applied on top after applying byte rate throttling if necessary. For example, if a large number of small produce requests are sent followed by a very large one, both request time quota and produce byte rate quota may be violated by the same request. The produce byte rate delay is applied first. Request time quota is checked only after the produce delay is applied. The request quota is perhaps no longer violated (or the delay may be lower due to the first byte-rate violation delay that has already been applied). The remaining delay if any If the request quota check still fails with quota violation, the delay for request quota violation is applied to the response.

...

Two new metrics and corresponding sensors will be added to track request-time and throttle-time of each quota entity for quota type IOThread.  The request-time sensor will be configured with the quota for the user/client so that quota violations can be used to add delays to the response. Quota window configuration (quota.window.size.seconds) will be the same as the existing configuration for produce/fetch quotas: 1 second window with 11 samples retained in memory by default. A new delay queue sensor will also be added for quota type IOThread. All the new sensor names (IOThread-<quota-entity>, IOThreadThrottleTime-<quota-entity> and IOThread-delayQueue) are prefixed by the quota type, making these sensors consistent with existing sensors for Produce/Fetch. The new metrics will be in the metrics group IOThread, distinguishing these from similar metrics for Produce/Fetch byte rates.

Metrics and sensors will be expired as they are today for Produce/Fetch quotas.

On the client side, a new sensor name request-throttle-time will be added to track request throttle time returned in responses. This is in addition to the similar sensor used to track produce/fetch throttle times, which will continue to be supported. Maximum and average throttle times for request time based throttling will be exposed as metrics in addition to throttle time metrics for produce/fetch byte rates.

Anchor
future future

Future Work

...