HTTP/2 multiplexes many streams onto a single TCP connection, so under high concurrency a single Jetty selector thread can become the bottleneck — every active stream's I/O event funnels through it. The platform shipped historical defaults of one acceptor and one selector ; on production nodes with more than four cores that combination produced long latency tails at p99 even when median latency was healthy.
This release switches to Jetty's standard heuristics — one acceptor plus max(1, cores/2) selectors. On a typical 8-vCPU production node that yields 1 acceptor and 4 selectors ; on 16-vCPU nodes 1 + 8. The selector saturation pattern is eliminated by spreading I/O events across enough threads to keep up with the active stream count, while the acceptor count stays low because connection establishment is rare relative to stream multiplexing.
Installations that need explicit tuning — air-gapped deployments with fixed thread budgets, multi-tenant nodes with heterogeneous load — can still set acceptor and selector counts through JVM system properties ; the change only moves the default.