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 [Change the link from KAFKA-1 to your own ticket]
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 new dynamic 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.replicas | A list of replicas for which log replication should be throttled on the follower side. |
| leader.replication.throttled.replicas | A list of replicas for which log replication should be throttled on the leader side. |
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