On 15/10/18 15:49, Rémy Maucherat wrote:
> Hi,
> 
> Looking at threads since there's a proliferation of executors and loose
> threads, I notice a possible refactoring:
> - start/stopExecutor is an obvious target, but by default is not there.
> However, it does not delegate to the parent container if not there.
> - The background thread is a loose thread, if the start/stopExecutor or
> whatever it is was a ScheduledThreadPoolExecutor, then it can probably be
> refactored.
> - Some executors in the clustering code, they could be run by that
> "start/stopExecutor" of thir parent container.
> - As for the catalina.Executor(s) in the Service, it could still wrap all
> this stuff, *if* our ThreadPoolExecutor used a ScheduledThreadPoolExecutor
> instead (at least as an option).
> 
> So .. Options are:
> a) Do nothing.
> b) Merge everything except catalina.Executor into a new
> ScheduledThreadPoolExecutor at the Container level (and delegate to
> parent), so the Engine will have it by default. Given how the background
> thread delay config and how startStopThreads work, this can remain mostly
> compatible, except some internal API from the start/stop executor is going
> to be gone.
> c) Merge everything into one executor. Hopefully NIO2 users remember they
> should give their connector its own executor.
> 
> So personally, I think b) is nice as the Excecutor is more for connector
> pools configuration

+1

> and we shouldn't pollute that with side uses. Is that
> doable in 9, or should it be added to the "10" todo list ?

No strong view. If it can be done without impacting the external API
then no objections here.

Mark

> 
> Comments ?
> 
> Rémy
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to