THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.
Status
Current state: Under Discussion
Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]
JIRA: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Motivation
KIP-226 added support for dynamic update of broker configuration. In this KIP, we propose to extend the support to dynamic update of a group of broker configs which will benefit the replication process.
Proposed Changes
| Config | Use case |
|---|---|
| fetch.max.bytes | Maximum bytes expected for the entire fetch response. |
| failed.authentication.delay | Connection close delay on failed authentication. |
| replica.fetch.response.max.bytes | Maximum bytes expected for the entire fetch response. |
| replica.fetch.wait.max.ms | Max wait time for each fetcher request issued by follower replicas. |
| follower.replication.throttled (new config to add) | Should all replication follower throttle |
| leader.replication.throttled (new config to add) | Should all replication leader throttle |
Public Interfaces
This KIP introduces:
- New broker level config parameter follower.replication.throttled - Should all replication follower throttle
- New replication config parameter leader.replication.throttled - Should all replication leader throttle
Compatibility, Deprecation, and Migration Plan
- There won't be any impact on existing users.
- There won't be any change of current behavior.
- No migration tool required