Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KAFKA-17578: Remove partitionRacks from TopicMetadata #17233

Merged
merged 1 commit into from
Sep 25, 2024

Conversation

FrankYang0529
Copy link
Member

The ModernGroup#subscribedTopicMetadata takes too much memory due to partitionRacks. This is not being used at the moment as the consumer protocol does not support rack aware assignments.

A heap dump from a group with 500 members, 2K subscribed topic partitions shows 654,400 bytes used for partitionRacks. The rest of the ConsumerGroup object holds 822,860 bytes.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@FrankYang0529 FrankYang0529 marked this pull request as draft September 19, 2024 12:37
Copy link
Contributor

@dajac dajac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FrankYang0529 Thanks for working on this. I left a few high level comments to start with.

* @return The set of racks corresponding to the replicas of the topic's partition.
* If the topic Id does not exist, an empty set is returned.
*/
Set<String> racksForPartition(Uuid topicId, int partition);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We cannot remove this from the public interface. Let’s return an empty set for now.

@@ -27,14 +27,7 @@
{ "name": "TopicName", "versions": "0+", "type": "string",
"about": "The topic name." },
{ "name": "NumPartitions", "versions": "0+", "type": "int32",
"about": "The number of partitions of the topic." },
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same. Unfortunately, we cannot remove fields because we released it. We must keep it. Let’s put a comment explaining that we don’t use it.

@dajac dajac added the KIP-848 The Next Generation of the Consumer Rebalance Protocol label Sep 19, 2024
return new TopicMetadata(
record.topicId(),
record.topicName(),
record.numPartitions(),
partitionRacks);
record.numPartitions());
}

public static TopicMetadata fromRecord(
ShareGroupPartitionMetadataValue.TopicMetadata record
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Not related to your changes but the indentation is incorrect here.

Comment on lines 126 to 128
record.topicId(),
record.topicName(),
record.numPartitions(),
partitionRacks);
record.numPartitions());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ditto.

@@ -242,27 +242,6 @@ private static void assertApiMessageAndVersionEquals(
assertEquals(expectedTopicMetadata.topicId(), actualTopicMetadata.topicId());
assertEquals(expectedTopicMetadata.topicName(), actualTopicMetadata.topicName());
assertEquals(expectedTopicMetadata.numPartitions(), actualTopicMetadata.numPartitions());

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that we can keep this code if we keep the fields in the record.

@FrankYang0529
Copy link
Member Author

Hi @dajac, thanks for review and suggestion. I addressed all comments. However, both GroupMetadataManagerTest#testGroupEpochBumpWhenNewStaticMemberJoins and GroupMetadataManagerTest#testNewJoiningMemberTriggersNewTargetAssignment are failed cases. I will try to fix them this weekend.

@FrankYang0529
Copy link
Member Author

Hi @dajac, I fixed both testGroupEpochBumpWhenNewStaticMemberJoins and testNewJoiningMemberTriggersNewTargetAssignment. Originally, different partitionRacks triggers subscription metadata update which generates a new consumer group subscription metadata record. Since we remove the field, we have to remove the related record in test cases.

@FrankYang0529 FrankYang0529 marked this pull request as ready for review September 21, 2024 06:43
@dajac
Copy link
Contributor

dajac commented Sep 21, 2024

@FrankYang0529 Thanks for the update. I am travelling today so I will review it on Monday.

@dajac
Copy link
Contributor

dajac commented Sep 23, 2024

@FrankYang0529 There are a few conflicts. Could you please address them?

Copy link
Contributor

@dajac dajac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@FrankYang0529 Thanks for the update. I left a few nits for consideration.

newSubscriptionMetadata.put(topicName, new TopicMetadata(
topicImage.id(),
topicImage.name(),
topicImage.partitions().size(),
partitionRacks)
topicImage.partitions().size())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Could you please put the last closing parenthesis on the next line?

 newSubscriptionMetadata.put(topicName, new TopicMetadata(
    topicImage.id(),
    topicImage.name(),
    topicImage.partitions().size()
));

return new TopicMetadata(
record.topicId(),
record.topicName(),
record.numPartitions(),
partitionRacks);
record.numPartitions());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Ditto about the closing parenthesis.

partitionRacks);
record.topicId(),
record.topicName(),
record.numPartitions());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ditto.

@FrankYang0529
Copy link
Member Author

Hi @dajac, thanks for the review. Updated it.

Copy link
Contributor

@dajac dajac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks.

@dajac dajac merged commit bb97d63 into apache:trunk Sep 25, 2024
9 of 10 checks passed
@FrankYang0529 FrankYang0529 deleted the KAFKA-17578 branch September 25, 2024 07:49
@dajac
Copy link
Contributor

dajac commented Sep 25, 2024

@FrankYang0529 Thanks for the patch. I just merged it. We need to work on another strategy to trigger rebalances based on rack changes. I have a few ideas. If you are interested, you could pick it up.

@FrankYang0529
Copy link
Member Author

Hi @dajac, I'm glad to handle it. Feel free to assign to me. Thank you 😄

@dajac
Copy link
Contributor

dajac commented Oct 9, 2024

@FrankYang0529
Copy link
Member Author

@FrankYang0529 I filed https://issues.apache.org/jira/browse/KAFKA-17747.

Thank you. May I try it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
KIP-848 The Next Generation of the Consumer Rebalance Protocol performance
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants