bozhao12 commented on code in PR #12078:
URL: https://github.com/apache/kafka/pull/12078#discussion_r868233936
##########
core/src/main/scala/kafka/server/DelayedFetch.scala:
##########
@@ -148,8 +148,8 @@ class DelayedFetch(delayMs: Long,
debug(s"Partition $topicIdPartition is in an offline log
directory, satisfy $fetchMetadata immediately")
return forceComplete()
case _: FencedLeaderEpochException => // Case E
- debug(s"Broker is the leader of partition $topicIdPartition, but
the requested epoch " +
- s"$fetchLeaderEpoch is fenced by the latest leader epoch,
satisfy $fetchMetadata immediately")
+ debug(s"The requested epoch $fetchLeaderEpoch of partition
$topicIdPartition" +
Review Comment:
@jolshan I understand one possible reason is that the server's check of the
leader epoch is consistent with the client's implementation.
The consumer sends a request to the leader replica, and the leader selects
the preferred read replica (possibly a follower replica) and returns it to the
consumer.The consumer then fetches data from the preferred read replica.
When the following cases occur, the consumer will return to fetch data from
the leader
case1: preferred read replica has expired
case2: received out of range exception from follower replica
case3: It is found that the latest leader epoch of the partition has changed
(usually from metadata).
When the consumer fetches data from the Follower replica. I think the epoch
check on the server side is consistent with case3.
--
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
