chia7712 commented on code in PR #17444:
URL: https://github.com/apache/kafka/pull/17444#discussion_r1820473003
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/modern/TopicMetadata.java:
##########
@@ -41,10 +41,25 @@ public class TopicMetadata {
*/
private final int numPartitions;
+ /**
+ * Map of every partition Id to a set of its rack Ids, if they exist.
+ * If rack information is unavailable for all partitions, this is an empty
map.
+ */
+ private final Map<Integer, Set<String>> partitionRacks;
Review Comment:
@dajac it seems the idea approach needs following advantages:
1. less computing
2. less stored objects
3. less new assignment
4. less coupling
Maybe we can leverage
[MetadataProvenance](https://github.com/apache/kafka/blob/trunk/metadata/src/main/java/org/apache/kafka/image/MetadataProvenance.java)?
It has an incremented offset that changes with new metadata images and is
small enough. We could store the offset in the group coordinator when the topic
topology changes. This approach addresses 'fewer stored objects,' 'fewer new
assignments,' and 'less coupling,' but still requires some computation to check
topology changes.
--
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
