dajac commented on code in PR #17444:
URL: https://github.com/apache/kafka/pull/17444#discussion_r1820345424
##########
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:
@chia7712 This is not how we have designed it. The group epoch is bumped to
trigger a re-computation of the target assignment. If the assignment does not
change, only the epoch of the target assignment is bump. End of the operation.
We don't need to compare assignments to not bump the group epoch is the first
place.
For the context, we designed the internal this way because computing the
assignment is the most heavy task in this process. We wanted to compute it only
when necessary.
> Do you mean all assignors should always generate the identical assignment
for the same input?
They should but this is not guaranteed by the interface so we must handle
all the cases. However, all the built-in assignors are sticky for sure.
> Sorry for the unclear comment. What I meant was that unrelated topic
changes, such as follower movements, can trigger a rebalance if we don’t track
the topic metadata (similar to my comment before
https://github.com/apache/kafka/pull/17444#discussion_r1817644544)
Right. This is why we must track the metadata to basically only trigger a
rebalance when there is a change in the racks.
--
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]
