junrao commented on code in PR #14111:
URL: https://github.com/apache/kafka/pull/14111#discussion_r1294873505
##########
clients/src/main/java/org/apache/kafka/clients/Metadata.java:
##########
@@ -114,18 +125,39 @@ public synchronized Cluster fetch() {
/**
* Return the next time when the current cluster info can be updated
(i.e., backoff time has elapsed).
+ * There are two calculations for backing off based on how many attempts
to retrieve metadata have been made
+ * since the last successful response, and how many equivalent metadata
responses have been received.
+ * The second of these allows backing off when there are errors to do with
stale metadata, even though the
+ * metadata responses are clean.
+ * <p>
+ * This can be used to check whether it's worth requesting an update in
the knowledge that it will
+ * not be delayed if this method returns 0.
*
* @param nowMs current time in ms
* @return remaining time in ms till the cluster info can be updated again
*/
public synchronized long timeToAllowUpdate(long nowMs) {
- return Math.max(this.lastRefreshMs + this.refreshBackoffMs - nowMs, 0);
+ // Calculate the backoff for attempts which acts when metadata
responses fail
+ long backoffForAttempts = Math.max(this.lastRefreshMs +
+ this.refreshBackoff.backoff(this.attempts > 0 ? this.attempts
- 1 : 0) - nowMs, 0);
+
+ // Periodic updates based on expiration are not backed off based on
equivalent responses
+ long backoffForEquivalentResponseCount;
+ if (Math.max(this.lastSuccessfulRefreshMs + this.metadataExpireMs -
nowMs, 0) == 0) {
Review Comment:
Instead of calculating the periodic refresh time, it's probably simpler to
just check `updateRequested()`?
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
