lianetm commented on code in PR #18050:
URL: https://github.com/apache/kafka/pull/18050#discussion_r1905871090
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/CommitRequestManager.java:
##########
@@ -196,6 +198,14 @@ public NetworkClientDelegate.PollResult poll(final long
currentTimeMs) {
return new NetworkClientDelegate.PollResult(timeUntilNextPoll,
requests);
}
+ private void maybeFailPendingRequestsOnCoordinatorFatalError() {
+ Optional<Throwable> fatalError =
coordinatorRequestManager.fatalError();
+ if (fatalError.isPresent()) {
+ pendingRequests.unsentOffsetCommits.forEach(request ->
request.future.completeExceptionally(fatalError.get()));
+ pendingRequests.unsentOffsetFetches.forEach(request ->
request.future.completeExceptionally(fatalError.get()));
Review Comment:
Agree, the `clearAll` was only being called from poll, when draining the
requests to send
https://github.com/apache/kafka/blob/bc3a18c59c638f267d9ebe28105be6b94f659f4f/clients/src/main/java/org/apache/kafka/clients/consumer/internals/CommitRequestManager.java#L193
If there was a fatal coordinator error, the poll does an early return so we
would never call `clearAll` and the failed requests would forever remain in the
queue I expect (even after expiration even, because the early return wouldn't
even allow to make it to the `failAndRemoveExpiredCommitRequests`). Makes sense
@kirktrue? (ln 207 doesn't have a clearAll so just want to make sure we're
looking at the same thing)
--
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]
