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
