m1a2st commented on code in PR #23014:
URL: https://github.com/apache/kafka/pull/23014#discussion_r3771389806
##########
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:
It used to be true because HB and Commit were the only managers that could
change state in a way the application thread needed to react to promptly, and
both only exist when the consumer is in a group. However, `FetchRequestManager`
now has the same kind of requirement.
I think it is safe to simply drop the
`isCommittedOffsetsManagementEnabled()` gate and always use:
`Math.min(applicationEventHandler.maximumTimeToWait(), timer.remainingMs())`
`applicationEventHandler.maximumTimeToWait()` already only reflects
`offsetsRequestManager`, `topicMetadataRequestManager`, and
`fetchRequestManager`, which are the three managers added unconditionally. The
first two do not override `maximumTimeToWait()`, so they default to
`Long.MAX_VALUE`.
Therefore, removing the gate does not introduce any HB/Commit-driven bound
for standalone consumers. There is nothing there to pull in.
Given that, I would propose removing the
`isCommittedOffsetsManagementEnabled()` check so that all consumers, whether
grouped or not, are bounded by whatever the request managers actually report.
Does that make sense?
--
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]
