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