> I'm aware of multiple ClientQuotaCallback implementations that rely on that method.
I'm curious about that too. As Kuan-Po mentioned, the method was completely unimplemented in KRaft mode until 4.0, which implies that is was not used by KRraf users. If there are users who avoided KRaft because of the absence of this method, that's actually a good thing - it gives us the opportunity to revisit the discussion around KIP-1162. Since `Cluster` is a heavy class, any alternative would require a number of public interfaces to wrap images in order to avoid performance issues. That's why I was in favor of simply deprecating the method Best, Chia-Ping Kuan-Po Tseng <brandb...@gmail.com> 於 2025年9月13日 週六 上午12:43寫道： > Hi Michael, > > > No alternative method will be introduced, as there is currently no known > demand > > for this functionality. > > Perhaps “no demand” was too strong a wording — apologies for that. > The real issue is that in 4.0 we reintroduced > ClientQuotaCallback#updateClusterMetadata(Cluster cluster) for KRaft > (it wasn’t available before then), but we didn’t handle it carefully. > This method comes with a number of potential pitfalls — especially the one > described in KAFKA-19122 < > https://issues.apache.org/jira/browse/KAFKA-19122> > . > > That’s why I initially proposed KIP-1162, which tries to redesign the > method. > But that proposal introduced quite a few changes, and the discussion > didn’t generate much feedback. > > Given that updateClusterMetadata is error-prone, fixing it properly would > require significant engineering effort, and, as far as we can tell, it’s > “almost” unused. This method wasn’t implemented for over three years > (since KRaft was introduced), no users have reported issues during that > time, > and it was only reintroduced in 4.0 about half a year ago. > > That’s why KIP-1200 proposes removing it altogether rather than redesigning > it. > See https://lists.apache.org/thread/otc7d6z19h5d86o17qr72g23wkxffkvo. > > I realize having two KIPs around the same method can be confusing. > My goal here is simply to address the underlying risk and find > the most practical resolution. Since we’re now voting on KIP-1200, > I consider KIP-1162 dropped, and I’ll make sure to clarify this > in the KIP-1200. Apologies for the confusion. > > As for this point: > > > I'm aware of multiple ClientQuotaCallback implementations that rely on > that method. > > From what I see in the Kafka trunk codebase, the only reference is in > DynamicTopicClusterQuotaPublisher#onMetadataUpdate. > Am I overlooking other usage? > > Best, > Kuan-Po Tseng > > On Sat, Sep 13, 2025 at 12:04 AM Mickael Maison <mickael.mai...@gmail.com> > wrote: > > > Hi, > > > > We have KIP-1162 to rethink ClientQuotaCallback. I think it would make > > sense to handle the deprecation of older APIs in that KIP. > > I'm not sure I understand why we have a separate KIP (this KIP). > > > > The KIP states "No alternative method will be introduced, as there is > > currently no known demand for this functionality.". > > How did you come to that conclusion? I'm aware of multiple > > ClientQuotaCallback implementations that rely on that method. > > Otherwise why would you also open KIP-1162, these 2 KIPs contradict > > each other! > > > > I don't want to vote for a feature to be deprecated and eventually > > removed without a clear plan for its users. > > > > Thanks, > > Mickael > > > > On Fri, Sep 12, 2025 at 2:03 AM Chia-Ping Tsai <chia7...@apache.org> > > wrote: > > > > > > hi kuan-po > > > > > > the KIP looks good to me. Do you plan to start the vote thread? > > > > > > Best, > > > Chia-Ping > > > > > > On 2025/07/30 16:17:46 Kuan-Po Tseng wrote: > > > > Hi folks, > > > > > > > > I'd like to start a discussion thread about deprecating > > > > ClientQuotaCallback#updateClusterMetadata. > > > > > > > > For more context and details, please refer to the KIP: > > > > https://cwiki.apache.org/confluence/x/axBJFg > > > > > > > > Thanks! > > > > > > > > Best regards, > > > > Kuan-Po Tseng > > > > > > >
