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 stateUnder Discussion

Discussion thread: here

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 operationally important broker configs which will benefit the replication process.

Proposed Changes

ConfigUse case
fetch.max.bytesMaximum bytes expected for the entire fetch response.
failed.authentication.delayConnection close delay on failed authentication.
replica.fetch.response.max.bytesMaximum bytes expected for the entire fetch response.
replica.fetch.wait.max.msMax wait time for each fetcher request issued by follower replicas.
replica.fetch.backoff.msThe amount of time to sleep when fetch partition error occurs.
replica.fetch.response.max.bytesMaximum bytes expected for the entire fetch response. 


fetch.max.bytes: ReplicaManager will multi-inherit from BrokerReconfigurable but no reconfigurable interfaces need to be implemented since the fetcher request will calculate fetchMaxBytes as the minimum of fetchRequest.maxBytes and config.fetchMaxBytes


failed.authentication.delay: SocketServer already implemented the Reconfigurable interface.  Setter method will be added in both Processor and Selector and update the Selector::failedAuthenticationDelayMsProp variable in the Reconfigure callback.


replica.fetch.response.max.bytes: The two class ReplicaAlterLogDirsThread and ReplicaFetcherThread read this config as their class variable when they initialize. So they will multi-inherit from BrokerReconfigurable and implemented setter method to modify the class variable in the Reconfigure callback.


replica.fetch.wait.max.ms: The changes are similar to replica.fetch.response.max.bytes


Public Interfaces


Compatibility, Deprecation, and Migration Plan

  • There won't be any impact on existing users.
  • There won't be any change in current behavior.
  • No migration tool required


Rejected Alternatives

  • No labels