junrao commented on code in PR #17739:
URL: https://github.com/apache/kafka/pull/17739#discussion_r1841103914
##########
core/src/main/java/kafka/server/share/SharePartition.java:
##########
@@ -1602,8 +1602,6 @@ protected void
updateFetchOffsetMetadata(Optional<LogOffsetMetadata> fetchOffset
protected Optional<LogOffsetMetadata> fetchOffsetMetadata() {
lock.readLock().lock();
try {
- if (findNextFetchOffset.get())
Review Comment:
Yes, I agree findNextFetchOffset=true is the uncommon case. It might be
useful to at least have some kind of consistent behavior for the uncommon case.
Since the minByte estimation will be off anyway in this case, we could choose
to consistent satisfy the request immediately or wait for the timeout. With the
logic in this PR, because fetchOffsetMetadata can be outdated in this uncommon
case, it's not clear when the request will be satisfied.
--
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
