hudeqi commented on code in PR #13719:
URL: https://github.com/apache/kafka/pull/13719#discussion_r1199814054
##########
core/src/main/scala/kafka/server/AbstractFetcherThread.scala:
##########
@@ -680,12 +680,15 @@ abstract class AbstractFetcherThread(name: String,
*/
val offsetAndEpoch = leader.fetchEarliestOffset(topicPartition,
currentLeaderEpoch)
val leaderStartOffset = offsetAndEpoch.offset
- warn(s"Reset fetch offset for partition $topicPartition from
$replicaEndOffset to current " +
- s"leader's start offset $leaderStartOffset")
val offsetToFetch = Math.max(leaderStartOffset, replicaEndOffset)
+ info(s"Reset fetch offset for partition $topicPartition from
$replicaEndOffset to " +
Review Comment:
> Why are we changing the log level? Moreover, by saying “new fetch offset”,
we lost the intention which is to reset to the leader start offset, no?
As discussed with kamalcph, if came here, there may be an unclean leader
election occurs, which need to be logged as info, because no data truncated and
resume from last fetch offset. the other case is need truncate fully and start
from leader's log start offset, which belongs to a "abnormal" case. when
executing the line log, we can not decide which case belong to. Or we may only
need to output warn log for "abnormal" case.
Resetting to leader's log start offset is only a possible case, so we can
ignore the intention of log start offset, because we have added a warn
log(start from log start offset for this case.) before executing
truncateFullyAndStartAt (log start offset).
--
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
