[ 
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)

Reply via email to