lianetm commented on code in PR #23014:
URL: https://github.com/apache/kafka/pull/23014#discussion_r3767060687
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/FetchRequestManager.java:
##########
@@ -69,6 +78,19 @@ protected void maybeThrowAuthFailure(Node node) {
networkClientDelegate.maybeThrowAuthFailure(node);
}
+ /**
+ * {@inheritDoc}
+ *
+ * If the most recent attempt to prepare fetch requests found nothing to
send solely because every candidate
+ * partition was skipped for a reason that only changes over time
(reconnect backoff, an in-flight request, etc.),
+ * nothing else will wake the application thread. In that case, its wait
is bounded by {@code retryBackoffMs} to
+ * ensure it wakes up and re-evaluates fetch eligibility periodically.
+ */
+ @Override
+ public long maximumTimeToWait(long currentTimeMs) {
Review Comment:
this is only used from the app thread if the consumer has a group.id. So
what about a consumer without group id using `assign`? If we cannot generate
any fetch request because of the reasons that "fix in time" (backoff), seems we
are leaving the app thread blocked for the full poll timeout?
The condition to use this req managers `maximumTimeToWait` only if in a
group was originally added because it was only the HB and Commit mgrs that
could change things that needed to unblock the app thread I expect. But with
this change the Fetch req manager also needs to unblock it now, so seems we
need to re-think that bit too? (I'm thinking out loud here, not fully sure yet
lol)
--
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]
