dajac commented on code in PR #17444:
URL: https://github.com/apache/kafka/pull/17444#discussion_r1818698890
##########
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:
> I don't think this is easy to follow. For instance, assignors typically
loop through members, topics, or partitions to calculate the assignment, but we
don't enforce a specific order for these objects in the input.
@chia7712 All the assignors are sticky and all new assignors must be sticky
too. This is a fundamental principle in KIP-848. That being said, as you said,
it depends on the implementation of the assignor so one can ignore this. Hence
they would get what they expect.
> We still need to track the 'state' of the current assignment to determine
whether 'the change is worth triggering a rebalance,' correct? I mean, how do
we ensure that the changes from GroupMetadataManager#onNewMetadataImage
actually require a rebalance?
We tack the topology of the group. This includes two things: 1) the members
and 2) the subscribed topics' partitions metadata. We trigger a rebalance
whenever on of them changes. Here we discuss how we could extend 2) to also
cover racks.
> my point was the approach you mentioned will trigger the assignment even
though the metadata is changed by unrelated topic.
This is incorrect. See my previous point. We actually have 2) to only
trigger a rebalance when the subscribed topics have changed.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
