lianetm commented on code in PR #21198:
URL: https://github.com/apache/kafka/pull/21198#discussion_r2662028745
##########
clients/src/main/java/org/apache/kafka/clients/consumer/internals/NetworkClientDelegate.java:
##########
@@ -221,13 +238,24 @@ boolean doSend(final UnsentRequest r, final long
currentTimeMs) {
log.debug("No broker available to send the request: {}.
Retrying.", r);
return false;
}
+
+ // Check if we're still in backoff period for this node
+ long backoffDelay = getBackoffDelay(node, currentTimeMs);
+ if (backoffDelay > 0) {
+ // Still in backoff period, skip retry
+ return false;
Review Comment:
This change means that we won't be checking the client readiness on every
poll of the network client anymore, right? I'm not sure that would be right
because client readiness to send can indeed change on any poll, and we don't
want to add unneeded delays in sending requests if the node becomes ready
(before the backoff expires)
Node readiness is about 2 things: being connected and being able to send
more requests (depending on in-flights and metadata requests, which are
prioritized based on this check). So on any call to poll, a client that was not
ready may become ready (ex. not ready because too many in-flights or metadata
needed + poll => ready).
I do see that the original Jira suggested backoff because of the noisy log
"Node is not ready" showing continuously, it's confusing. The continuous check
on client readiness, without backoff, is something we do want imo (we could
review the log level if we think it's too much). Thoughts? (I could be missing
something)
--
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]
