Spring-Boot on tsvinc

2492, 2495, 2508

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

Part 19 of the Micronaut native image series. Follows Part 18, which chased a connection pool cancellation leak. Assumes familiarity with JDBC, R2DBC, and JPA/Hibernate.

The Table That Ended the Argument

Workload	Framework	rps	p95
`jdbc-synth`	Quarkus	2508.4	1.2 ms
`jdbc-synth`	Micronaut	2495.0	1.8 ms
`jdbc-synth`	Spring Boot	2491.8	1.6 ms
`r2dbc-synth`	Quarkus	2501.2	1.4 ms
`r2dbc-synth`	Micronaut	2480.2	2.2 ms
`r2dbc-synth`	Spring Boot	2478.7	2.3 ms

Native images at 256 MB. Same k6 load. Same Postgres. Zero errors across the board.

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.

Four Bugs the Tests Couldn't See

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

Part 24 of the memory benchmark series. Follows Part 23, where six HTTP client swaps each OOM’d differently. Assumes familiarity with R2DBC, Hibernate Reactive, and connection pooling.

The senior code review on the first reactive port – Spring Boot 4.1 WebFlux and Quarkus 3.33 Hibernate Reactive, same app, same tests – came back clean. Field mapping: correct. Fan-out concurrency: correct. Scoring logic: correct. Native image hints: correct. Retry semantics: fixed (that was Part 21). All tests green.

Six OOMs and a Connection Pool

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

Part 23 of the Micronaut native image series. Follows Part 22, where the reactive ports reached throughput parity across three frameworks. Assumes familiarity with Spring’s RestClient and GraalVM native image.

The same 28-API fan-out app runs comfortably at 256 MB on Quarkus. Runs comfortably on Micronaut. On the imperative Spring Boot 4.1 port – Spring MVC, virtual threads, JdbcClient – it OOM’d. Then I fixed it and it OOM’d differently. Six benchmark runs. Six different failure modes. Each one peeling back a layer of what “choosing an HTTP client” actually means in a memory-constrained native image.

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.

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.

-Xmx Won't Save Your Native Image

Fri, 03 Jul 2026 00:00:00 +0000

Part 19 of the Micronaut native image series. Follows Part 18, where a reset Prometheus counter made the benchmark lie. Assumes familiarity with GraalVM native image and Docker memory limits.

The Confident Wrong Fix

# docker-compose.yml — the JVM reflex
environment:
  JAVA_TOOL_OPTIONS: "-Xmx128m"

Standard. Reliable. Every JVM deployment in every Kubernetes cluster in the world does this. It has never not worked.

It is a no-op on a native binary.

GraalVM native images are not JVMs. They don’t read JAVA_TOOL_OPTIONS. They don’t read -Xmx from environment variables. GraalVM issue #4650 requested this capability. Issue #9504 confirmed it’s still not supported. Your heap cap does nothing. No warning. No error. The binary starts, ignores the variable, sizes its heap however it wants.