-
Notifications
You must be signed in to change notification settings - Fork 14.6k
KAFKA-17302: ReplicaFetcher changes for fetching from tiered offset #20428
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: trunk
Are you sure you want to change the base?
Conversation
c125bd0
to
c07a3f6
Compare
408fb46
to
72a4dbf
Compare
72a4dbf
to
446efe0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @abhijeetk88 for the patch! Went over the first pass.
Could you explain why the TierStateMachine#buildRemoteLogAuxState
is not used to decide the offset-to-fetch either leaderLocalStartOffset
or lastTieredOffset
?
It fits nicely:
- Minimal code change and maintenance.
- If this code change is to handle the case when leader-log-start-offset == leader-local-log-start-offset == 0 and earliestUploadOffset > 0 (yet to be approved), then we may have to discuss it before proceeding with the patch. It is one of the edge-case but not sure how useful it would be in practice.
@@ -182,7 +179,7 @@ private void buildProducerSnapshotFile(UnifiedLog unifiedLog, | |||
* fetching records from the leader. The return value is the next offset to fetch from the leader, which is the | |||
* next offset following the end offset of the remote log portion. | |||
*/ | |||
private Long buildRemoteLogAuxState(TopicPartition topicPartition, | |||
protected Long buildRemoteLogAuxState(TopicPartition topicPartition, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: fix alignment
val earliestPendingUploadOffset = Math.max(highestRemoteOffset + 1, logStartOffset.offset()) | ||
val epoch = log.leaderEpochCache.epochForOffset(earliestPendingUploadOffset) | ||
|
||
new OffsetAndEpoch(earliestPendingUploadOffset, epoch.orElse(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
epoch 0 is vaild. If the epoch is empty, shall we return -1?
val leaderState = leaderPartitionState(topicPartition) | ||
checkLeaderEpochAndThrow(leaderEpoch, leaderState) | ||
val offsetAndEpoch = leaderState.earliestPendingUploadOffset match { | ||
case -1L => (-1L, -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can the OffsetAndEpoch be returned directly?
leaderState.earliestPendingUploadOffset match {
case -1L => new OffsetAndEpoch(-1L, -1)
case _ => new OffsetAndEpoch(math.max(leaderState.earliestPendingUploadOffset, leaderState.logStartOffset), leaderState.leaderEpoch)
}
expected: Boolean): Unit = { | ||
val tp = new TopicPartition("t", 0) | ||
|
||
def runScenario(enableLastTieredOffsetFetch: Boolean, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need this internal runScenario
method? Can this be flattened?
assertEquals(
expected,
thread.callShouldFetchFromLastTieredOffset(tp, leaderEndOffset, replicaEndOffset)
)
) | ||
} | ||
|
||
private class MockReplicaFetcherThread(name: String, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we remove this MockReplicaFetcherThread
and expose the shouldFetchFromLastTieredOffset
in RFT to server package?
override protected[server] def shouldFetchFromLastTieredOffset(topicPartition: TopicPartition, leaderEndOffset: Long, replicaEndOffset: Long): Boolean
Delete this text and replace it with a detailed description of your change. The
PR title and body will become the squashed commit message.
If you would like to tag individuals, add some commentary, upload images, or
include other supplemental information that should not be part of the eventual
commit message, please use a separate comment.
If applicable, please include a summary of the testing strategy (including
rationale) for the proposed change. Unit and/or integration tests are expected
for any behavior change and system tests should be considered for larger
changes.