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 >
