[
https://issues.apache.org/jira/browse/KAFKA-19566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai resolved KAFKA-19566.
------------------------------------
Fix Version/s: 4.4.0
Resolution: Fixed
> Deprecate ClientQuotaCallback#updateClusterMetadata
> ---------------------------------------------------
>
> Key: KAFKA-19566
> URL: https://issues.apache.org/jira/browse/KAFKA-19566
> Project: Kafka
> Issue Type: Improvement
> Reporter: Kuan Po Tseng
> Assignee: Kuan Po Tseng
> Priority: Major
> Fix For: 4.4.0
>
>
> In KAFKA-18225, we discovered that
> {{ClientQuotaCallback#updateClusterMetadata}} is not supported in KRaft mode,
> unlike in Zookeeper mode. Kafka 4.0 addressed this gap by implementing the
> method, but limitations remain:
> * A new {{Cluster}} object (immutable and heavyweight) is passed on every
> metadata update, which may cause memory pressure in large clusters (see
> KAFKA-18239).
> * Some {{Cluster}} fields are confusing or irrelevant in KRaft, such as
> {{controller()}} returning a random node for compatibility. Also, listener
> parsing differs between modes, potentially causing inconsistent partition
> info (see KAFKA-19122).
> To resolve these issues,
> *[KIP-1162|https://cwiki.apache.org/confluence/x/zInoF]* proposes a redesign
> of the method. However, given that this method remained unimplemented for
> years without user complaints, we believe it's not worth the complexity to
> fix it. Instead, we propose deprecating {{updateClusterMetadata}} now and
> removing it in Kafka 5.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)