Hi Chia-Ping, Thanks for the review and suggestions.
Q0: Add how rack change and how it affects topic partition. Q1: Add why we need a balance algorithm to Motivation section. Q2: After checking again, we don’t need to update cache when we replay records. We only need to renew it in consumer heartbeat. Q3: Add a new section “Topic Hash Function”. Thanks. PoAn > On Nov 1, 2024, at 4:39 PM, Chia-Ping Tsai <chia7...@gmail.com> wrote: > > hi PoAn > > Thanks for for this KIP! > > Q0: Could you add more details about `A topic partition has rack change`? > IIRC, the "rack change" includes both follower and leader, right? > > Q1: Could you please add the 'concerns' we discussed to the Motivation > section? This should include topics like 'computations' and 'space usage'. > > Q2: `The group coordinator can leverage it to add a new topic hash.`This > description seems a bit off to me. Why do we need to update the cache at > this phase? The cache is intended to prevent duplicate computations caused > by heartbeat requests that occur between two metadata change events. > Therefore, we could even remove the changed topics from caches on a > metadata change, as the first heartbeat request would update the caches for > all changed topics. > > Q3: Could you please include a section about the choice of hash > implementation? The hash implementation must be consistent across different > JDKs, so we use Murmur3 to generate the hash value. > > Best, > Chia-Ping > > > Frank Yang <yangp...@gmail.com> 於 2024年11月1日 週五 下午3:57寫道： > >> Hi all, >> >> I would like to start a discussion thread on KIP-1101. Trigger rebalance >> on rack topology changes. In this KIP, we aim to use less memory / disk >> resources to detect rack changes in the new coordinator. >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1101%3A+Trigger+rebalance+on+rack+topology+changes >> >> Please take a look and feel free to share any thoughts. >> >> Thanks. >> PoAn
