Claude
a7b76243fa
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.
47 lines
4.0 KiB
Markdown
47 lines
4.0 KiB
Markdown
# spring-async-demo
|
|
|
|
Companion code for the asynchronous execution and scheduling series on
|
|
[ankurm.com](https://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/README.md) | [@Async in Spring Boot 4: Executors, Virtual Threads and the Self-Invocation Trap](https://ankurm.com/spring-boot-4-async-executors-virtual-threads/) | Which thread a method actually ran on, in every case where the answer is not the one you expect |
|
|
| [`scheduling/`](scheduling/README.md) | [@Scheduled, ShedLock and Distributed Cron: Scheduling That Survives Three Replicas](https://ankurm.com/spring-scheduled-shedlock-distributed-cron/) | Three replicas against one database running the same job three times, then one row and one conditional UPDATE fixing it |
|
|
| [`awaitility/`](awaitility/README.md) | Testing Asynchronous Code with Awaitility (@Async, Kafka Listeners, Schedulers) | Replacing `Thread.sleep` with `await()` across a void `@Async` method, an `@KafkaListener`, and a `@Scheduled` job — plus the real pom.xml trap where Boot 4.1.1 split Kafka's autoconfiguration out of `spring-boot-autoconfigure` |
|
|
| [`virtual-threads-benchmark/`](virtual-threads-benchmark/README.md) | [Virtual Threads on Spring Boot 4.1: The Benchmarks, Re-Run, and the Pinning Advice That Expired](https://ankurm.com/leveraging-virtual-threads-in-spring-boot-3-4-building-high-throughput-services/) | 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-benchmark-webflux/README.md) | [Virtual Threads vs Reactive (WebFlux) vs Platform Threads: Benchmarks and a Decision Framework](https://ankurm.com/virtual-threads-vs-webflux-vs-platform-threads-spring-boot-benchmarks/) | 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](LICENSE).
|