Claude
09631dcaab
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.
3.6 KiB
spring-async-demo
Companion code for the asynchronous execution and scheduling series on
ankurm.com. Each
directory is a self-contained Maven project for one article, with its own pom.xml, its own
numbered documentation chapters, and its own captured output under docs/output/ — regenerated
by that module's scripts/run-all.sh, never typed by hand.
| Module | Article | What it demonstrates |
|---|---|---|
async/ |
@Async in Spring Boot 4: Executors, Virtual Threads and the Self-Invocation Trap | Which thread a method actually ran on, in every case where the answer is not the one you expect |
scheduling/ |
@Scheduled, ShedLock and Distributed Cron: Scheduling That Survives Three Replicas | Three replicas against one database running the same job three times, then one row and one conditional UPDATE fixing it |
virtual-threads-benchmark/ |
Virtual Threads on Spring Boot 4.1: The Benchmarks, Re-Run, and the Pinning Advice That Expired | Platform threads vs virtual threads, re-benchmarked on Boot 4.1.1 / JDK 25, plus JEP 491's fix to synchronized pinning proven against a real JDK |
virtual-threads-benchmark-webflux/ |
Virtual Threads vs Reactive (WebFlux) vs Platform Threads: Benchmarks and a Decision Framework | The WebFlux leg of the three-way comparison, plus the event-loop-starvation failure mode an isolated CPU benchmark can't show |
Common ground
All modules target the same verified stack: JDK 25 (Temurin 25.0.4.1+1), Spring Boot
4.1.1, Spring Framework 7.0.9. Versions were read from maven-metadata.xml on Maven Central
and from Boot's own spring-boot-dependencies POM, rather than from release announcements.
Everything is asserted by a test and captured to a file. The measurement is nearly always the same
one: the name of the thread that ran the work, returned by the code itself. Timing cannot tell a
fast synchronous call from an asynchronous one, which is why @Async failures survive so long in
production.
The two modules share a mechanism, which is why they live together: both @Async and ShedLock's
default PROXY_METHOD intercept mode are Spring AOP proxies. Every proxy limitation the async
module measures — self-invocation, final methods — applies unchanged to a
@SchedulerLock method, and silently produces an unlocked job rather than a synchronous one.
The scheduling module also needs a database. scheduling/scripts/postgres.sh unpacks a
throwaway PostgreSQL 14 into target/ with no Docker and no root, which is how its transcripts
were produced; docker-compose.yml is there for anyone who would rather use Docker.
virtual-threads-benchmark and virtual-threads-benchmark-webflux are a similar pair: the
first re-benchmarks platform threads against virtual threads for one post, the second adds the
WebFlux leg for a different, three-way-comparison post, and reuses the first module's
committed transcripts rather than re-measuring the same thing twice. Both use the same
client-side load generator (java.net.http.HttpClient on a virtual-thread executor, client
role only) so all three threading models in the three-way post are measured the same way.
Licence
MIT — see LICENSE.