Each HTTP request unnecessarily starts a new thread, resource leak.

[snazy]

Each HTTP request unnecessarily starts a new thread, resource leak.

[snazy]

j.u.Timer was introduced by #5372

/cc @zUniQueX

[snazy]

Or better: use a shared ScheduledThreadPoolExecutor instead of Timer

[zUniQueX]

@snazy Good catch. But I think your current implementation is also missing two aspects here:

• If Jetty's QTP utilizes all available processors for request handling and timeouts are frequent in some situation, the hard limit of the threads to a quarter of the available processors could lead to much higher timeouts. The delay in the ScheduledExecutorService is the minimum delay of the executor to wait before task execution, so the 'real' delay can be much higher. This wasn't a problem with the Timer implementation because there the timeouts were all handled just when the timeout occurred. I think the executor's pool size should be adjusted relative to Jetty's QTP size.
• If a request finishes in time, but some other requests are currently in timeout handling, the timeout task of the finished request will be kept in the executor's queue. The Jetty Scheduler implementation calls setRemoveOnCancelPolicy(true) to overcome this problem.

Having that said, I'm thinking, if it would be a good idea to utilize Jetty's Scheduler for the timeout handling. A Scheduler instance can be obtained via request.getComponents().getScheduler().