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

Sanjana Kaundinya commented on KAFKA-9800:
------------------------------------------

Here are my thoughts:
1) There should be no changes to the underlying NetworkClient interface. More 
details on what interfaces should change are outlined in the KIP 
[here]([https://cwiki.apache.org/confluence/display/KAFKA/KIP-580%3A+Exponential+Backoff+for+Kafka+Clients)|https://cwiki.apache.org/confluence/display/KAFKA/KIP-580%3A+Exponential+Backoff+for+Kafka+Clients).].
 As [~d8tltanc] mentioned, the key difference between the AdminClient and the 
other clients is that the AdminClient supports a per request timeout whereas 
the Producer and Consumer are using the NetworkClient to handle the timeouts. 
In our implementation we should add a per-request support for all clients and 
reuse the code existing in CallRetryContext to apply to all clients to do this.

2) I agree with [~ijuma], I don't see really much of a benefit for doing a 
different backoff strategy per client, plus that kind of improvement goes 
beyond the scope of this KIP.

 

[~d8tltanc] could you shed more light on how to refactor the AdminClient to 
take out the redundant logic? I want to understand how much this would change 
and if all this change would still be in the scope of the KIP.

> [KIP-580] Client Exponential Backoff Implementation
> ---------------------------------------------------
>
>                 Key: KAFKA-9800
>                 URL: https://issues.apache.org/jira/browse/KAFKA-9800
>             Project: Kafka
>          Issue Type: New Feature
>            Reporter: Cheng Tan
>            Assignee: Cheng Tan
>            Priority: Major
>              Labels: KIP-580
>
> In {{KafkaAdminClient}}, we will have to modify the way the retry backoff is 
> calculated for the calls that have failed and need to be retried. >From the 
> current static retry backoff, we have to introduce a mechanism for all calls 
> that upon failure, the next retry time is dynamically calculated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to