gt; > > > > > > > > > > > >
> > > > > > > > > > > > > > So if the user does override the "
> retry.backoff.ms" to a
> > > > value
> > > > > > > > > > larger
> > > > > > > > > > > > > than
> > > > > > > >
uozhang
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Mar 19, 2020 at 3:10 PM Jason Gustafson <
> > > > > > > > > ja...@confluent.io>
> > > > > > >
gt;>>> anyways.
> > > > > >>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> Guozhang
> > > > > >>>>>>>
> > > > > >>>>>>> On Thu, Mar 19, 202
> >>>>>>>> Hi Sanjana,
> > > > >>>>>>>>
> > > > >>>>>>>> The KIP looks good to me. I had just one question about the
> > > > >>> default
> > > > >>>>>>>&
>>>>>> there's no way to get the benefit of this feature if you are
> > > >>>>> providing
> > > >>>>>> a
> > > >>>>>>> `
> > > >>>>>>>> retry.backoff.ms` u
` unless you also provide `
> > >> retry.backoff.max.ms
> > >>> `.
> > >>>>> That
> > >>>>>>>> makes sense if you assume the user is unaware of the new
> > >>>>> configuration,
> > >>>>>>> but
> > >
and
> >>>>> since
> >>>>>>> the
> >>>>>>>> default you're proposing of 1s is fairly low already, I wonder
> >> if
> >>>>> it's
> >>>>>>> good
> >>>>>>>> enoug
t; add
>>>>>>>> any special logic. What do you think?
>>>>>>>>
>>>>>>>> -Jason
>>>>>>>>
>>>>>>>> On Thu, Mar 19, 2020 at 1:56 PM Sanjana Kaundinya <
>>>>>&
sed KIP, I think that makes a lot of
> > sense --
> > > > > as
> > > > > > > you
> > > > > > > > > mentioned in the motivation, we've indeed seen many issues
> > with
> > > > > > regard
> > > > > > > to
> > > regard
> > > > > > to
> > > > > > > > the frequent retries, with bounded exponential backoff in the
> > > > > scenario
> > > > > > > > where there's a long connectivity issue we would effectively
> > > red
gt; > > > > a retry logic but that's used in a slightly different way. For
> > > > example
> > > > > in
> > > > > > > Streams, we tend to handle the retry logic at the thread-level
> > and
> > > > > hence
> > > >
eams, we tend to handle the retry logic at the thread-level
> and
> > > > hence
> > > > > > very likely we'd like to change that mechanism in KIP-572
> anyways.
> > > For
> > > > > > producer / consumer / admin clients, I think just applying this
> > >
t; > > > behavioral
> > > > > change across these clients makes lot of sense. So I think can just
> > > leave
> > > > > the Streams / Connect out of the scope of this KIP to be addressed
> in
> > > > > separate discussions.
> >
> > > On Wed, Mar 18, 2020 at 12:09 AM Sanjana Kaundinya <
> > skaundi...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Thanks for the feedback Boyang.
> > > > >
> > > > > If there’s anyone e
18, 2020 at 12:09 AM Sanjana Kaundinya <
> skaundi...@gmail.com
> > >
> > > wrote:
> > >
> > > > Thanks for the feedback Boyang.
> > > >
> > > > If there’s anyone else who has feedback regarding this KIP, would
> > really
>
else who has feedback regarding this KIP, would
> really
> > > appreciate it hearing it!
> > >
> > > Thanks,
> > > Sanjana
> > >
> > > On Tue, Mar 17, 2020 at 11:38 PM Boyang Chen
> wrote:
> > >
> > > > Sounds great!
&g
preciate it hearing it!
> >
> > Thanks,
> > Sanjana
> >
> > On Tue, Mar 17, 2020 at 11:38 PM Boyang Chen wrote:
> >
> > > Sounds great!
> > >
> > > Get Outlook for iOS<https://aka.ms/o0ukef>
> > > ___________
na
>
> On Tue, Mar 17, 2020 at 11:38 PM Boyang Chen wrote:
>
> > Sounds great!
> >
> > Get Outlook for iOS<https://aka.ms/o0ukef>
> >
> > From: Sanjana Kaundinya
> > Sent: Tuesday, March 17, 2020 5:54:35 PM
>
ka.ms/o0ukef>
>
> From: Sanjana Kaundinya
> Sent: Tuesday, March 17, 2020 5:54:35 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] KIP-580: Exponential Backoff for Kafka Clients
>
> Thanks for the explanation Boyang. One of the most common problems that we
> ha
Sounds great!
Get Outlook for iOS<https://aka.ms/o0ukef>
From: Sanjana Kaundinya
Sent: Tuesday, March 17, 2020 5:54:35 PM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-580: Exponential Backoff for Kafka Clients
Thanks for the explanation Boyan
Thanks for the explanation Boyang. One of the most common problems that we have
in Kafka is with respect to metadata fetches. For example, if there is a broker
failure, all clients start to fetch metadata at the same time and it often
takes a while for the metadata to converge. In a high load
Thanks for the reply Sanjana. I guess I would like to rephrase my question
2 and 3 as my previous response is a little bit unactionable.
My specific point is that exponential backoff is not a silver bullet and we
should consider using it to solve known problems, instead of making the
holistic
Thanks for the feedback Boyang, I will revise the KIP with the mathematical
relations as per your suggestion. To address your feedback:
1. Currently, with the default of 100 ms per retry backoff, in 1 second we
would have 10 retries. In the case of using an exponential backoff, we would
have
Thanks for the KIP Sanjana. I think the motivation is good, but lack of
more quantitative analysis. For instance:
1. How much retries we are saving by applying the exponential retry vs
static retry? There should be some mathematical relations between the
static retry ms, the initial exponential
24 matches
Mail list logo
