lianetm commented on code in PR #23014:
URL: https://github.com/apache/kafka/pull/23014#discussion_r3767481134
##########
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) {
+ return shouldBoundMaximumTimeToWait ? retryBackoffMs : Long.MAX_VALUE;
Review Comment:
also thinking races now, the "prepare requests" that computes this
`shouldBoundMaximumTimeToWaitis` is triggered from the network thread before
polling, but then this `maximumTimeToWait` is used after the poll (so things
could change in-between)
https://github.com/apache/kafka/blob/500b73c097e05b50be02c891ad2ff1e94cd5742c/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java#L222-L237
Could that be an issue? Would it be safer to just determine the max wait
"live" here (e.g, return max if nodesWithPendingFetchRequests.isEmpty, and rely
on the subscription state to determine if we need backoff? )
--
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]
