Ismael Thanks for the feedback. 1/3 are in the pipeline.
re. 2 On some busy clusters a single metadata call has been observed to take order of ~100 milliseconds(I think it's mentioned somewhere in this motivation). So retrying immediately on the Produce path won't make sense, as metadata would still be stale. Hence the current proposal optimises for fetching specific-metadata about the new leader, in the produce & fetch response, outside of the metadata refresh. What do you think? On Thu, Jul 13, 2023 at 5:49 PM Ismael Juma <m...@ismaeljuma.com> wrote: > Thanks for the KIP. A couple of high level points and a more specific one: > > 1. Given the motivation, the performance results are essential for proper > evaluation, so I am looking forward to those. > 2. The reasoning given for the rejected alternative seems weak to me. It > would be useful to have numbers for that rejected alternative too. > 3, It's wasteful to repeat the leader node information for every partition > - we should probably have a separate list or map with the node information. > Looks like Jose suggested the same/similar. > > Ismael > > On Thu, Jul 13, 2023 at 7:16 AM Mayank Shekhar Narula < > mayanks.nar...@gmail.com> wrote: > > > Hi everyone > > > > Following KIP is up for discussion. Thanks for your feedback. > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-951%3A+Leader+discovery+optimisations+for+the+client > > > > -- > > Regards, > > Mayank Shekhar Narula > > > -- Regards, Mayank Shekhar Narula
