AsyncResponse timeout vs. manual watchdog for long-running requests

When implementing long-running operations in Dropwizard using @Suspended, there is a technical trade-off between utilizing Jersey's native AsyncResponse.setTimeout() and implementing a manual application-level watchdog.

The native approach relies on setting a server-side deadline via the AsyncResponse object. However, the underlying Jetty container does not always reliably trigger AsyncResponse.cancel() when a remote client aborts the connection. This can lead to orphaned background tasks continuing to consume resources even after the client has disconnected.

The alternative involves wrapping the work in a managed ExecutorService and using a separate ScheduledExecutorService to poll the request state or force cancellation. This bypasses the container-managed timeout semantics to provide more granular control over the lifecycle of the background operation.

• Does AsyncResponse.setTimeout() guarantee resource cleanup if the client socket is closed prematurely?
• Is a manual watchdog more effective for thread release compared to native Jersey timeout handlers under high concurrency?