Reactive on tsvinc

Eight Connections, Zero Available

Tue, 07 Jul 2026 00:00:00 +0000

Part 18 of the Micronaut native image series. Follows Part 17, which found that reactive and imperative produced identical throughput on the 28-API workload. Assumes familiarity with R2DBC and Project Reactor.

60.8 and 59.9

Two frameworks. Different HTTP servers, different dependency trees, different teams maintaining them. Under load, both reactive stacks land at almost the same throughput:

Framework	Model	Runtime	Mem	rps	p95	k6 errors
Micronaut	Reactive	Native	128 MB	60.8	15000.6 ms	14.1%
Spring Boot	Reactive	Native	128 MB	59.9	13548.7 ms	2.0%
Micronaut	Imperative	Native	256 MB	251.9	2554.8 ms	0%
Spring Boot	Imperative	Native	256 MB	220.6	2588.9 ms	0%
Quarkus	Reactive	Native	256 MB	258.7	—	0%

Imperative hits 220–252. Quarkus reactive hits 259. Micronaut and Spring Boot reactive: 60.

Every Route Registered. Every Request 404'd.

Mon, 06 Jul 2026 00:00:00 +0000

Thirty-three routes registered. Startup log confirms it. The /routes management endpoint lists every one. And under load, every single request returns 404.

This is the reactive Micronaut branch of the space observatory benchmark — 28 upstream API calls, 10 HTTP clients, all pointed at a Go mock server that deliberately injects failures (HTTP 500, 504-after-delay, abrupt connection close). The imperative sibling branch works. The lighter synth variant works. This one: 100% 404.

Three Front Doors, One Engine

Sun, 05 Jul 2026 00:00:00 +0000

Part 22 of the Micronaut native image series. Follows Part 21, where a retry was mistranslated two ways. Assumes familiarity with reactive Java (Mono/Flux/Uni) and at least one of the three frameworks.

The experiment

Same app. Same Java 25. Same GraalVM CE 25. Same Postgres. Same Liquibase schema. Same benchmark harness. Three frameworks.

The app fans out to 28 HTTP APIs concurrently, computes risk scores across seismic, atmospheric, and space weather data, and writes one row to Postgres. Six endpoints. The heaviest hits all 28 APIs in four parallel blocks. Built on Micronaut 5.0.0 with reactive R2DBC. Ported to Spring Boot 4.1 and Quarkus 3.33.

1% CPU and 6-Second Latency

Sat, 04 Jul 2026 00:00:00 +0000

Part 20 of the Micronaut native image series. Follows Part 19, where a native image OOM’d at 256MB. Assumes familiarity with reactive Java and connection pooling.

Quarkus 3.33. Hibernate Reactive Panache. Mutiny. GraalVM native image in a 256MB container. Six endpoints, each fanning out to 28 mock APIs via Uni.combine, computing risk scores, persisting one row. The near-identical Spring WebFlux port did 100 req/s.

Quarkus did 18.8.

Average latency: 6.4 seconds. p95: 16 seconds. 33% of k6 checks failing. And the CPU was at 1%.

Two ways to mistranslate a retry

Sat, 04 Jul 2026 00:00:00 +0000

Part 21 of the Micronaut native image series. Follows Part 20, where two stacked bottlenecks throttled Quarkus. Assumes familiarity with declarative HTTP clients and retry semantics.

Porting 10 HTTP clients from Micronaut to Quarkus and Spring Boot produced two retry bugs. One framework over-retried by ~50%. The other silently never retried HTTP 5xx at all. Both ports passed every functional test. Both shipped code comments claiming parity with the original.

The bugs were mirror images, caused by completely different mechanisms, and invisible without a benchmark that injects failures and counts upstream calls.

The Throughput Was Always 115

Thu, 02 Jul 2026 00:00:00 +0000

Part 17 of the Micronaut native image series. Follows Part 16, which compared reactive vs imperative on a lighter workload. Assumes familiarity with Project Reactor and virtual threads.

115

That’s the number. Requests per second. For all twelve scenarios.

Reactive R2DBC on native: 115. Imperative JDBC on JVM: 115. Virtual threads with loom-carrier: 114.5. Reactive on JVM with 512 MB memory limit: 115.2. Imperative on JVM unlimited: 115.1.

Twelve benchmark runs. Two codebases. Three runtime configurations. Six memory/container permutations each. 0% failure rate across the board. And the same number, over and over, like a metronome that doesn’t care what’s playing.

Designed a Reactive Benchmark. Imperative Won.

Tue, 30 Jun 2026 00:00:00 +0000

Part 16 of the Micronaut native image series. Follows Part 15, which benchmarked the reactive service alone. Assumes familiarity with Project Reactor and virtual threads.

The Hypothesis

The workload was designed to make reactive shine. Six endpoints exercising parallel fan-out, scatter-gather, bounded concurrency, and backpressure. A Go mock server injecting realistic latency jitter — ISS at 10-50ms with 3% failures, NEO at 30-150ms, connection resets via Hijack() + conn.Close(). k6 ramping to 200 VUs then sustaining 500 req/s constant arrival. If reactive Micronaut had a home-court advantage anywhere, it was here.

265 req/s on All Three Runtimes (Until You Add a Memory Limit)

Sat, 27 Jun 2026 00:00:00 +0000

Part 15 of the Micronaut native image series. Assumes familiarity with reactive Java (Mono/Flux) and container memory limits.

The Draw

Native image, JVM, and virtual threads walk into a benchmark. Same reactive Micronaut service. Same k6 load profile. Same PostgreSQL. Same mock APIs with realistic latency jitter.

Runtime	Req/s	Errors	RSS (avg)
Native (unlimited)	264	1.0%	273 MB
JVM (unlimited)	266	1.0%	551 MB
Virtual threads (unlimited)	265	1.0%	543 MB

265 req/s. All three. The error rates match the mock server’s configured failure rate — the application itself isn’t failing. Reactive code runs identically on native image, HotSpot, and loom-carrier Netty.

We Removed Reactor. Nothing Got Slower.

Sat, 20 Jun 2026 00:00:00 +0000

We took the entire reactive stack out. R2DBC, Mono, Flux, Reactor Core, loom-carrier, flatMap with its carefully-tuned concurrency arguments. Replaced it with JDBC, HikariCP, and blocking method calls. Same endpoints. Same Netty HTTP server. Same PostgreSQL. Same k6 load profile: 10 to 200 VUs, 500 req/s constant arrival rate, seven scenarios each.

Throughput didn’t move. Latency dropped. Memory dropped. GC pauses dropped 63% at 256 MB.

The Scoreboard

This is part of the series benchmarking a Micronaut 5.0.0 app under memory constraints. The reactive version is the one from Part 10 and Part 11 — fully tuned, flatMap concurrency bounded, R2DBC pool sized to match, loom-carrier enabled for virtual threads. The imperative version: JDBC/HikariCP, THREAD_PER_TASK executor for virtual threads, same pool size.

flatMap's Second Argument Saved 1.7 Million Requests

Mon, 15 Jun 2026 00:00:00 +0000

Midway through a code review of the reactive pipeline, staring at this line in NeoService.java:

.flatMap(neo -> saveAsteroidWithApproaches(sessionId, neo))

That’s Flux.flatMap() with one argument. The function. No concurrency limit. Reactor’s default: 256 concurrent inner subscriptions.

The R2DBC connection pool has 20 connections. Netty has 4 worker threads. flatMap will cheerfully create 256 concurrent database save operations on 20 connections and 4 threads, queuing 236 of them in memory. Every one holds a NeoAsteroidRecord entity, a NeoCloseApproach list, and whatever intermediate state Reactor needs for the inner publisher chain.