You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "David Jacot (Jira)" <ji...@apache.org> on 2025/01/22 08:43:00 UTC
[jira] [Resolved] (KAFKA-18583) Improve/fix KRaftMetadataCache.getPartitionReplicaEndpoints
[ https://issues.apache.org/jira/browse/KAFKA-18583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Jacot resolved KAFKA-18583.
---------------------------------
Resolution: Fixed
> Improve/fix KRaftMetadataCache.getPartitionReplicaEndpoints
> -----------------------------------------------------------
>
> Key: KAFKA-18583
> URL: https://issues.apache.org/jira/browse/KAFKA-18583
> Project: Kafka
> Issue Type: Task
> Components: core
> Affects Versions: 3.9.0, 3.7.2, 3.8.1
> Reporter: Dimitar Dimitrov
> Assignee: Dimitar Dimitrov
> Priority: Blocker
> Fix For: 4.0.0, 3.9.1, 3.8.2
>
>
> The {{KRaftMetadataCache.getPartitionReplicaEndpoints}} method, called when a replica selector is being used (e.g. for Fetch From Follower), currently takes a single {{TopicPartition}} for which to calculate node endpoints per replica ID, but then goes on to process all the partitions of the topic. As a result it seems to both calculate endpoints which are not relevant for the given partition and to recalculate the relevant endpoints multiple times as replicas of many different partitions.
> This could be very detrimental to performance if it touches topics with larger number of partitions.
> Unlike its KRaft counterpart, {{ZkMetadataCache.getPartitionReplicaEndpoints}} seems to do the right thing, processing only the partition info of the given partition. Also the problem doesn't seem to be a recent regression - it looks like it was present in the original form of {{KRaftMetadataCache}} introduced more than 3 years ago.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)