[
https://issues.apache.org/jira/browse/KAFKA-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17043866#comment-17043866
]
ASF GitHub Bot commented on KAFKA-9047:
---------------------------------------
skaundinya15 commented on pull request #8161: KAFKA-9047: Making AdminClient
group operations respect retries and backoff
URL: https://github.com/apache/kafka/pull/8161
https://issues.apache.org/jira/browse/KAFKA-9047
Previously, `AdminClient` group operations did not respect a `Call`'s number
of configured tries and retry backoff. This could lead to tight retry loops
that put a lot of pressure on the broker. This PR introduces fixes that ensures
for all group operations the `AdminClient` respects the number of tries and the
backoff a given `Call` has.
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
> AdminClient group operations may not respect backoff
> ----------------------------------------------------
>
> Key: KAFKA-9047
> URL: https://issues.apache.org/jira/browse/KAFKA-9047
> Project: Kafka
> Issue Type: Bug
> Components: admin
> Reporter: Jason Gustafson
> Assignee: Sanjana Kaundinya
> Priority: Major
>
> The retry logic for consumer group operations in the admin client is
> complicated by the need to find the coordinator. Instead of simply retry
> loops which send the same request over and over, we can get more complex
> retry loops like the following:
> # Send FindCoordinator to B -> Coordinator is A
> # Send DescribeGroup to A -> NOT_COORDINATOR
> # Go back to 1
> Currently we construct a new Call object for each step in this loop, which
> means we lose some of retry bookkeeping such as the last retry time and the
> number of tries. This means it is possible to have tight retry loops which
> bounce between steps 1 and 2 and do not respect the retry backoff.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
