v1.61.0 regression: all HTTP requests hang on Spring Boot 3.5.x + Undertow + Java 21

[prash3232]

Bug Report

Summary

After upgrading from v1.60.4 to v1.61.0, all inbound HTTP requests hang indefinitely on services running Spring Boot 3.5.x with the Undertow web server on Java 21. The JVM starts successfully, the port binds, and application logs show "Started in X seconds" — but every HTTP request (including health probes) connects at TCP level and receives zero bytes, causing Kubernetes liveness/readiness probes to fail and CrashLoopBackOff.

Update (2026-04-14): We have narrowed the affected combination to Spring Boot 3.5.x + Undertow. Services on Spring Boot 3.4.x with the same Undertow setup and the same v1.61.0 agent do not exhibit this behaviour. See additional notes below.

Environment

Field	Value
dd-java-agent version	v1.61.0
Last working version	v1.60.4
Java version	21 (OpenJDK / Eclipse Temurin)
Framework	Spring Boot 3.5.x (confirmed 3.5.5 and 3.5.13)
Web server	Undertow (embedded, Tomcat excluded)
Runtime	Containerised (Kubernetes / EKS)
OS	Linux (distroless/debian base image)

Symptoms

• Application starts successfully (no exception in startup logs)
• Port 8080 is bound and accepting TCP connections
• All HTTP requests hang — TCP connects but zero bytes returned
• Not endpoint-specific: /actuator/health, /info, and all app endpoints affected
• Kubernetes readiness/liveness probes time out → pod restarts → CrashLoopBackOff
• Reverting to v1.60.4 immediately resolves the issue with no other changes

Reproduction Steps

1. Run a Spring Boot 3.5.x application with Undertow (Tomcat excluded) on Java 21
2. Add dd-java-agent.jar from v1.61.0 as a JVM agent (-javaagent:/dd-java-agent.jar)
3. Start the application — it will appear healthy in logs
4. Send any HTTP request — it will hang indefinitely

Workaround

Pin to v1.60.4:

https://github.com/DataDog/dd-trace-java/releases/download/v1.60.4/dd-java-agent.jar
SHA256: c55578cf5b1c14bcb33c2c9405e03f1e0c99e68d48cd12fb5ac9430d1013576b

Impact

Any service using the floating URL https://dtdg.co/java-tracer-v1 in its Dockerfile that rebuilt after April 8 (when v1.61.0 was published) will silently pick up v1.61.0 and enter CrashLoopBackOff — if it is on Spring Boot 3.5.x + Undertow.

We have confirmed multiple independent services affected by this combination.

Additional Notes

• Spring Boot 3.4.x is NOT affected: We have a service with the identical stack (Undertow, Java 21, Kubernetes, same Dockerfile pattern) on Spring Boot 3.4.5 — it pulled v1.61.0 and operates normally. This strongly suggests the regression is triggered by a change introduced in Spring Boot 3.5.x's Undertow integration (possibly virtual thread handling, request handler chain registration, or I/O filter changes).
• Once Datadog releases a fix, we plan to unpin and resume tracking the latest version
• We are happy to provide debug logs, JVM thread dumps, or any other diagnostics if helpful

[dougqh]

Thank you for the bug report. We'll look into creating a reproducer and let you know if we need information.

[mahatmus-tech]

Same problem here. Pinned to v.1.60.4 solved it.

[dougqh]

We tried creating a reproducer using a Spring demo application with undertow on Java 21.
Unfortunately, the demo application was unable to recreate the hang described.

If either of you could provide a thread dump, we would greatly appreciate it.

[prash3232]

Thanks for trying to reproduce, @dougqh!

A key detail that may help: we have narrowed this down to Spring Boot 3.5.x specifically. We have a service on the identical stack (Undertow, Java 21, same Dockerfile, same Kubernetes environment) running Spring Boot 3.4.5 that pulled v1.61.0 and operates completely normally. The affected services are all on Spring Boot 3.5.5 and 3.5.13.

It's likely the demo app used for reproduction is on an older Spring Boot version — reproducing with Spring Boot 3.5.x + Undertow (Tomcat excluded) may trigger the hang.

Regarding thread dumps — we have already rolled back to v1.60.4 across our affected services to restore production stability, so we can't easily collect a thread dump from a live v1.61.0 instance right now. If you can share a minimal reproducer (e.g., a Spring Boot 3.5.x + Undertow app with a single REST endpoint), we can try to run it locally against v1.61.0 and capture a thread dump for you.

@mahatmus-tech — could you confirm what Spring Boot version your affected service is using?

[matsudayousuke]

We experienced the same issue in our production environment on April 9, 2026, one day after v1.61.0 was released.

Environment:

• Java 21 (OpenJDK 21+35-2513), aarch64 (ARM64, AWS Graviton)
• Spring Boot 3.5.12 with embedded Tomcat
• Amazon ECS (Fargate)
• Agent flags: -Ddd.profiling.enabled=true -Ddd.logs.injection=true -Ddd.integration.jdbc-datasource.enabled=true -Ddd.dbm.propagation.mode=full -Ddd.dbm.trace_prepared_statements=true -Ddd.dynamic.instrumentation.enabled=true

Symptoms:

• Application started normally — no errors in startup logs, Spring Boot banner displayed, Tomcat port bound successfully
• All HTTP requests hung: TCP connections were accepted but no response bytes were returned
• ALB health checks timed out, ECS marked tasks as unhealthy and entered a restart loop
• ~3,700 502/504 errors over ~1 hour 43 minutes
• The agent startup log confirmed "version":"1.61.0~aa7c70f2e7" on the affected tasks

How we confirmed it was v1.61.0:

• Our Dockerfile downloaded dd-java-agent.jar from https://dtdg.co/latest-java-tracer without version pinning
• v1.61.0 was released on April 8; our deploy on April 9 picked it up automatically
• Multiple revert/redeploy attempts failed because they all pulled the same v1.61.0
• Pinning to v1.60.3 immediately resolved the issue — all tasks became healthy within minutes

What we don't have:

• Unfortunately we do not have a thread dump from the affected tasks. The issue has been resolved by pinning to v1.60.3, and we no longer have tasks running v1.61.0. We also do not have easy access to run jstack inside ECS Fargate containers during an incident.

Hope this helps narrow down the reproduction conditions.

[prash3232]

@matsudayousuke thank you — this is a very important data point!

Your report confirms that the regression is not specific to Undertow — it also affects embedded Tomcat on Spring Boot 3.5.x. Combined with our finding that Spring Boot 3.4.x + Undertow is unaffected, this strongly points to something in Spring Boot 3.5.x core (not the embedded server implementation) as the trigger.

Summary of what we now collectively know:

Spring Boot	Web Server	Java	Affected?
3.5.13	Undertow	21	✅ Yes
3.5.5	Undertow	21	✅ Yes
3.5.12	Tomcat	21	✅ Yes
3.4.5	Undertow	21	❌ No

@dougqh — reproducing with Spring Boot 3.5.x + either Tomcat or Undertow + Java 21 should now be much more reliable. The issue appears to be in how v1.61.0 instruments something that changed in the Spring Boot 3.5.x request processing pipeline (possibly related to virtual threads, Micrometer Observation, or the new lifecycle changes in 3.5).

[PerfectSlayer]

Hello, Bruce from Datadog here 👋

Thanks for the reports. We are still working on a reproducer.
We were able to reproduce and fix on our staging environment but we are still looking for more feedback.

Would you have the opportunity to test this dev build and report if you still have issue?
It’s coming from our CI and here is the related pull request if you would like to check the changes / build it yourself: #11111