hachikuji commented on code in PR #14053:
URL: https://github.com/apache/kafka/pull/14053#discussion_r1351005643
##########
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:
I was actually debating it. Do we create a race on the leader for a
restarted broker? A restarted broker will typically not be in the ISR, so
perhaps a delay for propagation of the registration state would not have any
adverse effects. What do you think?
--
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
