Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Update state to Adopted and add link to the discussion thread

...

Table of Contents

Status

Current stateUnder DiscussionAdopted

Discussion thread: here

JIRA:

Jira
serverASF JIRA
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyKAFKA-3878

...

Introduce a new client config for producer consumer and admin client `reconnect.backoff.max` max.ms` defined as:

The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. The actual backoff will be determined randomly, with uniform distribution, to To avoid connection storms. In practice the average backoff when this threshold is hit will be (reconnect.backoff.max - reconnect.backoff.ms) / 2., a randomization factor of 0.2 will be applied to the backoff resulting in a random range between 20% below and 20% above the computed value.

This config will default to 1000ms if `reconnect.backoff` is not set explicitly. Otherwise, it will default to the same value as `reconnect.backoff`.

...

  1. Provide a pluggable interface for reconnect attempts like in KIP-53: it seems like we can provide the desired functionality via a single config so pluggability is not worth the additional complexity.
  2. Default `reconnect.backoff.max` max.ms` to the same value as `reconnect.backoff` backoff.ms` so that existing behaviour is always maintained: for the reasons explained in the compatibility section
  3. Default `reconnect.backoff.max` max.ms` to `1000ms` unconditionally: for the reasons explained in the compatibility section.

...