bartoszkobylinski commented on issue #3748: URL: https://github.com/apache/iggy/issues/3748#issuecomment-6665548763
Hi @hubcio — I've completed the verification. Thanks for pointing me to #4629 and #4683! I reproduced the original busy-polling issue and tested the new deferred polling implementation against the same workload. **Environment** - GitHub Actions `ubuntu-latest` (Linux) - Server container and Python client pinned to CPU 0 - 60 seconds idle, followed by 5 individual messages sent 3 seconds apart - Servers: `apache/iggy:0.8.0` and `apache/iggy:edge` (reporting v0.10.0) - Python SDK: `apache-iggy` 0.8.0 and 0.9.1.dev10 **Results** | Configuration | Server CPU | Client CPU | Context switches/s | Delivery latency | |---|---:|---:|---:|---| | 0.8, no `poll_interval` | 35.4% | 31.0% | ~94,600 | 1, 1, 1, 1, 1 ms | | 0.8, `poll_interval=250ms` | 0.07% | 0.09% | ~450 | 243, 9, 9, 11, 9 ms | | 0.10, default polling | 0.57% | 0.03% | ~800 | 2, 1, 1, 1, 1 ms | | 0.10, `max_wait=30s`, `Auto(Processing)` | 0.78% | 0.03% | ~690 | 2, 1, 1, 1, 1 ms | The original busy loop was reproduced across three runs (server CPU 34–41%, client CPU 27–31%). **The fix is confirmed for this workload.** The new idle consumer adds no measurable CPU overhead above the server's idle baseline (approximately 0.3–0.6%), while delivering messages in 1–2 ms in these tests. Two additional observations: 1. **Old client / new server compatibility:** The 0.8.0 Python client against the 0.10.0 server appeared to hang instead of reporting an actionable incompatibility error. The test eventually timed out after 10 minutes, while the server repeatedly logged `consensus client disconnected`. An explicit protocol-version error would help diagnose partial upgrades. 2. **`PollOptions` without `max_wait`:** With an explicitly supplied `PollOptions(commit=Auto)` but no `max_wait`, one of five messages took approximately 1002 ms to arrive. This did not reproduce the busy loop. It may be worth clarifying the semantics of `max_wait=None` versus omitting `poll_options` entirely. These are observations from a small verification run, not claims of separate confirmed regressions. Thanks again for the fixes and for following up on the original report. This is a substantial improvement for idle Python consumers! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
