Dropwizard Jetty thread-pool and queue sizing for bursty concurrent traffic without latency spikes

I am configuring a Dropwizard service (assuming Dropwizard 2.x/3.x with the default embedded Jetty server) that must absorb short bursts of concurrent requests without the latency inflation that appears when the Jetty thread pool saturates and requests pile up in the bounded queue.

The documented server.applicationConnectors and thread-pool settings (minThreads, maxThreads, workQueueSize) are static, and I cannot find a built-in mechanism that scales the pool or applies back-pressure based on observed queue depth. Metrics exposes latency histograms and Jetty queue gauges, but nothing in the configuration reference indicates that these can drive automatic adjustment.

The missing constraint is a sizing rule: given a known peak concurrency and average per-request blocking time, what is a defensible way to choose maxThreads and workQueueSize so the queue never grows deep enough to dominate 95th-percentile latency, while also avoiding excessive threads that increase GC and memory pressure?

Specifically:

• Is there a documented relationship or recommended formula between expected concurrent in-flight requests, blocking I/O duration, and maxThreads in Dropwizard/Jetty?
• Should the bounded queue be kept deliberately small to fail fast, and if so, what status/behavior does Jetty produce when the queue is full?
• Is there any supported hook for back-pressure or dynamic pool resizing, or is manual tuning the only option?