chirag-wadhwa5 commented on code in PR #18696:
URL: https://github.com/apache/kafka/pull/18696#discussion_r1935509143
##########
core/src/main/java/kafka/server/share/SharePartition.java:
##########
@@ -2160,6 +2234,43 @@ private long startOffsetDuringInitialization(long
partitionDataStartOffset) thro
}
}
+ // Visible for testing
+ long findLastOffsetAcknowledged() {
+ lock.readLock().lock();
+ long lastOffsetAcknowledged = -1;
+ try {
+ for (NavigableMap.Entry<Long, InFlightBatch> entry :
cachedState.entrySet()) {
+ InFlightBatch inFlightBatch = entry.getValue();
+ if (inFlightBatch.offsetState() == null) {
+ if
(!isRecordStateAcknowledged(inFlightBatch.batchState())) {
+ return lastOffsetAcknowledged;
+ }
+ // If initialReadGapOffset.gapStartOffset is less than or
equal to the last offset of the batch
+ // then we cannot identify the current inFlightBatch as
acknowledged. All the offsets between
+ // initialReadGapOffset.gapStartOffset and
initialReadGapOffset.endOffset should always be present
+ // in the cachedState
+ if (initialReadGapOffset != null &&
inFlightBatch.lastOffset() >= initialReadGapOffset.gapStartOffset()) {
+ return lastOffsetAcknowledged;
+ }
Review Comment:
I think you are right. initialReadGapOffset is always populated with the
result of read state state response. So, this possibility might never occur. I
will remove this check and push another commit. Thanks !
--
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
