Claude
b331db6638
Fixes two bugs 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. - 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; raised to 60 concurrent requests (matching the CPU-bound benchmark's own concurrency) so the load actually occupies the event loop for the full window. Also adds StreamBackpressureTest, a StepVerifier proof that the /stream endpoint never emits ahead of its subscriber's outstanding requests.
14 lines
726 B
Plaintext
14 lines
726 B
Plaintext
Flux backpressure proof: /stream, requested in batches of 3, 2, then 45
|
|
=======================================================================
|
|
StepVerifier.create(controller.streamResults(), 3)
|
|
.expectNext("event-0", "event-1", "event-2")
|
|
.expectNoEvent(Duration.ofMillis(80)) -- no 4th item arrives without a request
|
|
.thenRequest(2).expectNext("event-3", "event-4")
|
|
.thenRequest(45).expectNextCount(45)
|
|
.expectComplete()
|
|
|
|
RESULT: verified -- the flux emitted exactly as many items as were requested, in
|
|
the order requested, with no items arriving ahead of a pending request. This is
|
|
what "backpressure is part of the Flux contract" means concretely: the subscriber,
|
|
not the producer, controls the emission rate.
|