[
https://issues.apache.org/jira/browse/KAFKA-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860642#comment-16860642
]
ASF GitHub Bot commented on KAFKA-8503:
---------------------------------------
huxihx commented on pull request #6913: KAFKA-8503: Ignore retries config if a
custom timeout is provided
URL: https://github.com/apache/kafka/pull/6913
https://issues.apache.org/jira/browse/KAFKA-8503
When custom timeout is provided, `retries` config could be ignored for
individual APIs in KafkaAdminClient. Tweaked code path for `Call.fail` to pass
NPathComplexity check.
*More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.*
*Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.*
### 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:
us...@infra.apache.org
> AdminClient should ignore retries config if a custom timeout is provided
> ------------------------------------------------------------------------
>
> Key: KAFKA-8503
> URL: https://issues.apache.org/jira/browse/KAFKA-8503
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jason Gustafson
> Assignee: huxihx
> Priority: Major
>
> The admin client takes a `retries` config similar to the producer. The
> default value is 5. Individual APIs also accept an optional timeout, which is
> defaulted to `request.timeout.ms`. The call will fail if either `retries` or
> the API timeout is exceeded. This is not very intuitive. I think a user would
> expect to wait if they provided a timeout and the operation cannot be
> completed. In general, timeouts are much easier for users to work with and
> reason about.
> A couple options are either to ignore `retries` in this case or to increase
> the default value of `retries` to something large and not likely to be
> exceeded. I propose to do the first. Longer term, we could consider
> deprecating `retries` and avoiding the overloading of `request.timeout.ms` by
> providing a `default.api.timeout.ms` similar to the consumer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
