Covers replacing Thread.sleep with await() across a void @Async method, an
@EmbeddedKafka-backed @KafkaListener, and an already-running @Scheduled job;
verifies Awaitility 4.3.0's real defaults (10s timeout, 100ms poll interval)
and its default-uncaught-exception-handler swap directly against the jar;
and documents a real pom.xml trap where Boot 4.1.1 split Kafka's
autoconfiguration (spring-boot-kafka) out of spring-kafka itself, which
silently leaves @KafkaListener beans with no running container.
Fixes found during self-correction before publishing:
- /stream used Flux.interval(), which ticks on its own wall-clock schedule
independent of downstream demand and threw OverflowException under a slow
subscriber; switched to Flux.range(), which has no independent production
schedule and can never outrun demand.
- Single-trial HTTP load tests on this shared sandbox swung by more than 50%
run to run (795ms-1247ms observed on the identical /io endpoint back to
back) -- large enough to flip which threading model looked faster. Fixed
by taking the median of 5 independent trials for the I/O-bound benchmark
and the median of 3 for the event-loop-starvation benchmark, rather than
reporting a single noisy run as if it were precise.
- The event-loop-starvation test's first cut used only 8 concurrent /cpu
requests as background load, which drained through the 4 event-loop
threads well inside the /io measurement window and produced an
inconsistent, sometimes-inverted result across runs; raising to 60 fixed
the under-loading problem but still flaked once during verification
(372ms vs 374ms p99, a real tie). Final fix: 150 concurrent requests plus
the median-of-3 trials above.
Also adds StreamBackpressureTest, a StepVerifier proof that the /stream
endpoint never emits ahead of its subscriber's outstanding requests, and
updates the module's docs to report the de-noised numbers with an explicit
methodology note on how they compare to the single-trial platform/virtual-
thread numbers reused from a different post.
Claude