jolshan commented on code in PR #14444:
URL: https://github.com/apache/kafka/pull/14444#discussion_r1361003116
##########
core/src/main/scala/kafka/server/KafkaApis.scala:
##########
@@ -559,6 +560,26 @@ class KafkaApis(val requestChannel: RequestChannel,
}
}
+ case class LeaderNode(leaderId: Int, leaderEpoch: Int, node: Node)
+
+ private def getCurrentLeader(tp: TopicPartition): LeaderNode = {
+ val partitionInfoOrError = replicaManager.getPartitionOrError(tp)
+ val (leaderId, leaderEpoch) = partitionInfoOrError match {
+ case Right(x) =>
+ (x.leaderReplicaIdOpt.getOrElse(-1), x.getLeaderEpoch)
+ case Left(x) =>
+ debug(s"Unable to retrieve local leaderId and Epoch with error $x,
falling back to metadata cache")
+ metadataCache.getPartitionInfo(tp.topic, tp.partition) match {
+ case Some(pinfo) => (pinfo.leader(), pinfo.leaderEpoch())
+ case None => (-1, -1)
+ }
+ }
+ val leaderNode: Node = metadataCache.getAliveBrokerNode(leaderId,
config.interBrokerListenerName).getOrElse({
Review Comment:
Hmmm -- I'm not sure I understand "more commonly used path".
ReplicaManager will have the partition if the broker hosts it. The
metadatacache is meant to be a cache of all the partitions, so I don't think it
loses out on "caching benefits"
The benefit of the replica manager is that it also contains the log of the
partition. If the metadata cache is sufficient (which it seems to be) we should
probably just use that.
--
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
