Versions Compared

Old Version 2

changes.mady.by.user Kowshik

Saved on

compared with

New Version 3

changes.mady.by.user Kowshik

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Feature advertisements from each broker in the cluster are reactively picked up by the controller via ZK watches. Today these watches are already set up by the controller on every broker’s ephemeral ZK node (at /brokers/ids/<id>). The contents of the broker nodes are cached in memory in the Controller.

...

  • In the UpdateMetadataRequest request handler path, we will populate the MetadataCache with the latest list of finalized features as sent to it by the controller (also see Broker protections section in this doc).

  • We will modify the implementation of the ApiKeys.API_VERSIONS API to populate the information about finalized features in the response. This will contain the cluster-wide finalized versions from the broker’s internal MetadataCache (as explained above), as well as the broker-level supported versions.

  • The finalized feature versions populated in the response will be eventually consistent, since it is served from information propagated via ApiKeys.UPDATE_METADATA API by the controller.

...