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
