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
