Jetty version(s)

ee8

Jetty Environment

HTTP version

HTTP/1.1

Java version/vendor (use: java -version)

Open JDK 21

OS type/version

Windows Server running on AWS EC2
Exact OS build can be provided if needed.

Description
We observed a production application inaccessibility issue where the Jetty server stopped serving requests. The JVM was still running, but the application became inaccessible/timeouts were observed from the client/load balancer side.

We collected 5 thread dumps over approximately 100 seconds. The dumps consistently show almost all Jetty qtp worker threads waiting on the same java.util.concurrent.locks.ReentrantLock$NonfairSync object inside Jetty HttpChannelState.onIdleTimeout.

Summary from the thread dumps:

Dominant thread stack pattern:

java.lang.Thread.State: WAITING (parking)
- parking to wait for <0x0000000659c60e40>
  (a java.util.concurrent.locks.ReentrantLock$NonfairSync)

at java.util.concurrent.locks.ReentrantLock.lock
at org.eclipse.jetty.util.thread.AutoLock.lock
at org.eclipse.jetty.ee8.nested.HttpChannelState.lock
at org.eclipse.jetty.ee8.nested.HttpChannelState.onIdleTimeout
at org.eclipse.jetty.server.internal.HttpChannelState.lambda$onIdleTimeout$0
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob

The same lock object was seen across thousands of Jetty threads:

0x0000000659c60e40

This resulted in Jetty thread-pool starvation. The configured Jetty qtp pool had around 3750 threads, but most of them were parked/waiting in the Jetty HTTP channel idle-timeout path. Because the worker pool was exhausted, new requests could not be processed, causing the application to become inaccessible.

We also observed at least one application request thread trying to write/commit a response through Jetty:

org.eclipse.jetty.ee8.nested.HttpChannelState.commitResponse
org.eclipse.jetty.ee8.nested.HttpChannel.sendResponse
org.eclipse.jetty.ee8.nested.HttpOutput.write
org.apache.jsp.web.view.mail.agent.reply.showinlineattachment_jsp._jspService

We did not find evidence in the dumps of a normal Java monitor deadlock, database pool exhaustion, Redis blockage, or GC pause being the direct cause. The dominant issue appears to be Jetty internal HttpChannelState lock contention during idle-timeout processing.

thread_dump_5944__2026-05-29 13-27-15.zip

thread_dump_5944__2026-05-29 13-27-15.zip

We would like Jetty guidance on the following:

Is this a known Jetty 12.x issue or failure mode?
Can this be triggered by a large number of client-disconnected, aborted, timed-out, or idle connections?
Are there known fixes in Jetty 12.1.x related to this HttpChannelState.onIdleTimeout lock contention/server hang behavior?
What Jetty tuning is recommended to avoid this condition?

How to reproduce?

We do not yet have a fully deterministic reproduction for the exact Jetty internal lock contention.

The issue was observed under production traffic. Based on the thread dumps, the suspected trigger is a large number of HTTP channels entering idle-timeout handling while Jetty worker threads are already under pressure.