chia7712 commented on code in PR #17444:
URL: https://github.com/apache/kafka/pull/17444#discussion_r1820899350
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/Utils.java:
##########
@@ -235,4 +238,20 @@ public static ApiMessage
messageOrNull(ApiMessageAndVersion apiMessageAndVersion
return apiMessageAndVersion.message();
}
}
+
+ public static long hashSubscriptionMetadata(Map<String, TopicMetadata>
subscriptionMetadata) {
Review Comment:
> Why not using a single hash? The issue is that we don't always know which
topics have changed (e.g. after a coordinator failover) so we have to recompute
the cache anyway.
As @FrankYang0529 explained, we calculate the hash of topics as needed. For
example:
1. We can rebuild the cache for all subscribed topics during a metadata
update.
2. Alternatively, the calculation can occur when we need to call
group.computeSubscriptionMetadata, and we remove the topic hash from the cache
if the topics have changed during a metadata update.
By the way, here are the approaches we've discussed:
1. TopicMetadata: Not optimal for space.
2. Single Hash: Not efficient for computing, as a change in one topic could
trigger all related groups to recalculate the hash.
3. Hash per Topic: Balances space and computation by using a cache.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
