dajac commented on code in PR #17444:
URL: https://github.com/apache/kafka/pull/17444#discussion_r1820753168
##########
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.
> The coordinator will maintain an in-memory cache Map<UUID, Integer> where
the key is the topic UUID and the value is the hash based on 'name + partitions
+ racks'.
If we store a hash per topic, it should be stored by topic name because
member subscribe by topic name and we must also catch the topic recreation.
> The cache will be updated whenever a group needs to calculate the hash for
an uncached topic or when new metadata brings a topic change.
Could you elaborate on how this will work?
--
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
