AsyncResponse timeout vs. manual watchdog for long-running requests

Direct answer

No. AsyncResponse.setTimeout() does not guarantee resource cleanup when a client socket closes early. It registers a server-side deadline and invokes the TimeoutHandler only after that deadline expires; it is not a disconnect detector and it does not interrupt the application thread running the long operation. A manual watchdog is not automatically more effective under high concurrency. It provides more deterministic cleanup only when the background task can be cooperatively cancelled—by polling isCancelled() or responding to Thread.interrupt()—and when per-request scheduled tasks are properly shut down.

Confirmed behavior

• setTimeout() is a server-side deadline, not a client-abort signal.
• Jetty may not invoke AsyncResponse.cancel() immediately when the remote client drops the connection.
• The application must check isCancelled() inside the long-running task and release executor, database, or socket resources itself.
• Uninterruptible work, such as a blocking JDBC call without its own query timeout, will not release the thread just because the response timed out.

When a manual watchdog helps

A ScheduledExecutorService watchdog that calls cancel() and interrupts the worker is useful when you need finer-grained control than the container timeout provides, or when you cannot rely on Jetty to notify the application of a premature close. The trade-off is overhead: one scheduled task per request can pressure the scheduler under high concurrency, and an unguarded cancel() after the response already completed can throw or be ignored.

Steps for this case

1. Keep setTimeout() as the outer safety net so the container eventually reclaims the async context.
2. Inside the suspended resource, submit work to a bounded ExecutorService and pass the AsyncResponse to the worker.
3. Have the worker poll asyncResponse.isCancelled() at each stage and return early if true, closing statements, streams, and HTTP clients.
4. Add a manual watchdog only if the task is interruptible and you need cleanup faster than the native timeout allows. Schedule a single task per request that calls asyncResponse.cancel() and workerThread.interrupt(), then remove it in a finally block once the response completes.
5. Guard every watchdog cleanup call so it runs only if the response is still active.

Missing diagnostic detail

Can the background task cooperatively check isCancelled() and respond to Thread.interrupt()? This determines whether a watchdog is worth the added overhead or whether native timeout plus listener instrumentation is sufficient.

Verification

Run the request, close the client early, and check jstack <pid> to confirm the worker thread leaves RUNNABLE or WAITING and returns to baseline. Log isCancelled() at task start, at each cancellation check, and inside the TimeoutHandler. Add a Jetty AsyncListener to record onComplete, onTimeout, and onError so you can see whether premature client close reaches the container. Repeat with the exact production Dropwizard, Jersey, and Jetty versions, with and without the watchdog, and compare orphaned tasks against thread count. This behavior is version-sensitive; verify against your exact release before relying on it in production.