junrao commented on code in PR #17539:
URL: https://github.com/apache/kafka/pull/17539#discussion_r1817943465
##########
core/src/main/java/kafka/server/share/SharePartition.java:
##########
@@ -1525,6 +1537,24 @@ private Optional<Throwable> acknowledgeCompleteBatch(
return Optional.empty();
}
+ protected void updateLatestFetchOffsetMetadata(LogOffsetMetadata
fetchOffsetMetadata) {
+ lock.writeLock().lock();
+ try {
+ latestFetchOffsetMetadata = fetchOffsetMetadata;
Review Comment:
@adixitconfluent : Here is the rough idea.
1. If endOffset advances forward, we incrementally update its file position
by the size of batches going forwarded.
2. The tricky thing is how the offset metadata picks up a new segment being
rolled. As we increase the file position, endOffset will eventually reach the
baseOffset of the next segment. This means that the next fetch request will be
satisfied immediately since the HWM is on a different segment. When we acquire
the data (for batches at the beginning of the segment), we can check if the
offset metadata in the fetch data has the same offset as endOffset but on a
different segment. If so, we update the offset segment of endOffset.
3. If the endOffset goes backward (due to timeout/acknowledgements/release)
or endOffset is being initialized for the first time, we just call readFromLog
to get the offset metadata.
4. `tryComplete` will have the same logic to deal with the uncommon cases
where the offset metadata is not available or the offset metadata is on the
same segment. The only difference is that it won't update
latestFetchOffsetMetadata any more since the update happens when endOffset
changes.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
