Hi
Guess this utility should be there very early so before other starts/stops
sounds good but ultimately init/destroy is better since it avoids to create
custom utility threads in subcomponents init/destroy (more destroy for real
cases I think, not sure for init).
What about getting it injected from the context and ignoring its lifecycle
("external" notion)? Will keep it globally usable and integrate smoothly
with any env.
Le ven. 28 avr. 2023 à 04:27, Han Li <li...@apache.org> a écrit :
>
>
> > On Apr 28, 2023, at 00:33, Mark Thomas <ma...@apache.org> wrote:
> >
> > 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.
>
> Maybe ContainerBase#startStopExecutor also need same operation above?
>
> >
> > 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?
> + 1
>
> >
> > Mark
> >
> > [1] https://github.com/spring-projects/spring-boot/issues/34955
> >
> > ---------------------------------------------------------------------
> > 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
>
>
