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

[snazy]

Each instance of org.glassfish.jersey.jetty.JettyHttpContainer.ResponseWriter implicitly starts a new thread, because each request creates a new instance of java.util.Timer - and these timer threads do not stop. A big request rate can easily start thousands of timer threads.

From the javadoc of java.util.Timer:

Implementation note: All constructors start a timer thread.

and:

After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully (and becomes subject to garbage collection). However, this can take arbitrarily long to occur.

So I think that creating a new j.u.Timer instance for every request is not a great solution. A better option would be to have only one timer per container.

[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().

[senivam]

@snazy, @zUniQueX what do you think about the #5611?

[zUniQueX]

@senivam Looks good to me 👍

[jansupol]

Closing as completed via #5611