[jira] [Commented] (KAFKA-8503) AdminClient should ignore retries config if a custom timeout is provided

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-8503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025304#comment-17025304 ] 

ASF GitHub Bot commented on KAFKA-8503:
---------------------------------------

hachikuji commented on pull request #8011: KAFKA-8503; Add default api timeout to AdminClient (KIP-533)
URL: https://github.com/apache/kafka/pull/8011
 
 
   This PR implements `default.api.timeout.ms` as documented by KIP-533. This is a rebased version of #6913 with some additional test cases and small cleanups.
   
   Co-authored-by: huxi <hu...@hotmail.com>
   
   ### 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:
users@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
(v8.3.4#803005)