Hi Andrew, Thanks for the clarification and for asking the relevant committers to take a look. I’ll continue using the document to discuss and refine the internal design, without planning for a formal KIP vote.
Thanks, Eric. On Tue, Sep 22, 2026 at 3:42 PM Andrew Schofield <[email protected]> wrote: > > Hi Eric, > Thanks for the KIP. I understand the problem you are trying to solve and it > does need attention. But as an internal design improvement, it doesn't need a > KIP. We can definitely use the KIP document as a way to discuss the best > approach, but you will not need to get this voted because it does not make > external changes. I expect they're already aware, but I will ping some of the > committers with experience in this area to make sure they take a proper look. > > Thanks, > Andrew > > On 2026/09/22 03:02:46 Eric Chang wrote: > > Hi everyone, > > > > I would like to start the discussion for KIP-1371: > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=449282795 > > > > Several async-consumer busy-loop fixes share the same pattern: a > > request-manager timer reaches zero while an in-flight request, > > unavailable coordinator, or another prerequisite prevents the related > > work from progressing. Existing fixes replace that zero with another > > configured duration. This repairs the individual path, but the > > replacement may also be zero and can make correctness depend on a > > timing configuration. > > > > KIP-1371 proposes an internal `ManagerPollCondition` type with three > > explicit conditions: > > > > - `ready()`: another local step can run immediately. > > - `after(...)`: time can make another pass useful. > > - `idle()`: the work has no local deadline and needs another event > > before it can progress. > > > > Each request-manager `poll()` returns its outgoing requests together > > with the condition for its next pass. The same owner-local decision > > can govern request admission and network scheduling, while > > `either(...)` preserves independent deadlines such as > > `max.poll.interval.ms`. > > > > The proposal retains the current deadline-driven network loop, manager > > order, thread topology, public APIs, protocols, configuration, > > metrics, and existing wakeup paths. It applies to the async > > request-manager loop shared by regular, share, and Streams consumers. > > > > The KIP uses KAFKA-20253, KAFKA-20970, KAFKA-21010, and KAFKA-21031 as > > evidence for the recurring problem and explains how the proposed > > conditions represent those cases. > > > > Feedback on the problem statement, condition model, and proposed > > migration scope would be appreciated. > > > > Thanks, > > Eric > >
