On Fri, Apr 28, 2023 at 3:35 PM Konstantin Kolinko <knst.koli...@gmail.com> wrote: > > пт, 28 апр. 2023 г. в 16:21, Konstantin Kolinko <knst.koli...@gmail.com>: > > > > чт, 27 апр. 2023 г. в 19:34, Mark Thomas <ma...@apache.org>: > > > > > > Hi all, > > > > > > As part of a discussion around a Spring Boot issue [1], the question has > > > been raised whether there is merit in moving the Utility executor > > > start/stop from StandardServer init/destroy to start/stop. > > > > > > I've looked at the code and I don't see any uses of the Executor until > > > sub-components are in the start phase (there is a little copying of > > > references that might need to move) so I think the change is doable. > > > > > > The main advantage is that in the embedded scenario where there might be > > > a long series of start / stop / start / stop etc, shutting down the > > > executor on stop should avoid issues where executor tasks are not > > > shutdown correctly. My brief code review suggested that Tomcat does this > > > correctly but the executor is also exposed to application code. > > > > > > Thoughts? > > > > > > Mark > > > > > > [1] https://github.com/spring-projects/spring-boot/issues/34955 > > > > +1. > > > > It sounds reasonable, and thinking about Tomcat being started by > > Commons Daemon jsvc, I think that init() should not be used to start > > utility threads. > > > > If it causes a regression (I mean, if something really needs to be > > done at init() time), one may implement a Listener. > > Looking at when a Connector starts its pool of threads, > > o.a.c.connector.Connector.initInternal() does > > // Initialize adapter > adapter = new CoyoteAdapter(this); > protocolHandler.setAdapter(adapter); > if (service != null) { > > protocolHandler.setUtilityExecutor(service.getServer().getUtilityExecutor()); > } > > So it also needs a change.
I noted down that item already (simply looking at all the getUtilityExecutor calls, basically), it's simply that the pool is available in init, so it's set up in the endpoint at that time because "why not", but it's not actually used yet. Rémy > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
