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 and we shouldn't pollute that with side uses. Is that doable in 9, or should it be added to the "10" todo list ? Comments ? Rémy
