CalvinConfluent commented on code in PR #14053:
URL: https://github.com/apache/kafka/pull/14053#discussion_r1352848836
##########
core/src/main/scala/kafka/cluster/Replica.scala:
##########
@@ -98,14 +105,22 @@ class Replica(val brokerId: Int, val topicPartition:
TopicPartition) extends Log
* fetch request is always smaller than the leader's LEO, which can happen
if small produce requests are received at
* high frequency.
*/
- def updateFetchState(
+ def updateFetchStateOrThrow(
followerFetchOffsetMetadata: LogOffsetMetadata,
followerStartOffset: Long,
followerFetchTimeMs: Long,
leaderEndOffset: Long,
brokerEpoch: Long
): Unit = {
replicaState.updateAndGet { currentReplicaState =>
+ val cachedBrokerEpoch = if
(metadataCache.isInstanceOf[KRaftMetadataCache])
+
metadataCache.asInstanceOf[KRaftMetadataCache].getAliveBrokerEpoch(brokerId)
else Option(-1L)
+ // Fence the update if it provides a stale broker epoch.
+ if (brokerEpoch != -1 && cachedBrokerEpoch.exists(_ > brokerEpoch)) {
Review Comment:
Maybe allowing the updates with higher broker epochs has one problem. Is it
possible there is a malfunctioning/bug broker to fetch with a crazy broker
epoch, then the leader has to restart to get out of the state. Other than this,
I don't see a problem to allow higher broker epoch.
--
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
