lianetm commented on code in PR #18737:
URL: https://github.com/apache/kafka/pull/18737#discussion_r1954494541
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/AbstractMembershipManager.java:
##########
@@ -818,6 +826,8 @@ void maybeReconcile() {
return;
}
+ if (autoCommitEnabled && !canCommit) return;
Review Comment:
Agree, and it's the same situation for the auto-commit on the interval too.
We this we're now ensuring that both auto-commits are triggered only at the
beginning of each app poll iteration if needed (so we know that allConsumed
positions are accurate), but we also need to ensure that the app thread won't
move on (to fetching) until those positions are actually retrieved.
Given that the `PollEvent` processing is completely async (does not block on
any request or callback, just triggers async commits if needed, and
reconciliation, which is also completely async), would it make sense to have
the app thread wait on the completion of the `PollEvent` before moving on?
This only means that the app thread would wait for the async requests to be
generated (with the allConsumed when needed), not waiting on send or responses.
Thoughts?
--
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
