THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Configuration Management
How do we manage the quota overrides and the default topic configs? Manually configuring brokers with these is painful. In this case, the ability to dynamically change configs without bouncing brokers is very useful. There is already a proposal/patch for dynamic configuration management by Joe Stein which we plan to leverage for distributing these quota configs. In the future, we also need to think about restricting access to these configs (so that customers cannot modify their own quotas) but that is a separate discussion.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-5+-+Broker+Configuration+ManagementWe need a mechanism to configure the default quotas and the per-user overrides. There is general agreement that we eventually need dynamic configs per-user to fully operationalize quotas but for the purposes of this proposal, we will proceed with static configs.
| Code Block |
|---|
// Default bytes-out per consumer.
quota.consumer.default=2M
quota.producer.default=2M
// Overrides
quota.producer.override="clientA:4M;clientB:10M"
quota.consumer.override="clientC:3M;clientD:5M" |
Tooling/Monitoring Changes
Along with this feature, we are proposing to add the following tools/admin operations:
- Dynamically disable/enable quota enforcement for the entire cluster. Such a feature is very useful while rolling out this feature to production environments.
- Ability to disable quotas on a per-client basis. For example: we may not want to throttle mirror makers.
- Dynamically change quotas for any client id.
We also plan to expose the fraction of quota used on a per-client basis via JMX (0-100%, where 100 means throttled).
Compatibility, Deprecation, and Migration Plan
...
B) If we instead model the quotas on a per-topic basis, provisioned quota can be split equally among all the partitions of a topic. For example: If a topic T has 8 partitions and total configured write throughput of 8MBps, each partition gets 1Mbps. If a broker hosts 3 leader partitions for T, then that topic is allowed 3MBps on that broker regardless of the partitions that traffic is directed to. In terms of quota distribution, this is the most elegant model.
Quota Actions
A) Immediately return an error: This is the simplest possible option. However, this requires clients to implement some sort of a back off mechanism since retrying immediately will likely make things worse.
B) Delay the request and return error: If a client is currently exceeding its quota, we can park the request in purgatory for 'n' milliseconds. After the request expires, the broker can return an error to the client. This is a nice feature because it effectively throttles the client up to the request timeout and makes it less critical for them to implement backoff logic. After the error is caught by the client, they can retry immediately. Note that in case of producers, we should be careful about retaining references to large Message bodies because we could easily exhaust broker memory if parking hundreds of requests. The downside of this approach is that it requires the clients to catch quota violation errors and retry their requests.
...
There is more context of the email thread on this particular issue.