On Fri, Apr 28, 2023 at 8:10 AM Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
>
> 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).
The Server starts first and stops last, so it seems it will be fine. I
don't quite see why it is a good idea to do utility tasks in init or
destroyed (they should happen in start or stop).
Right now the only item which needs to change is that the connector
endpoint gets it on init. The other components were using it on start.
Remy
> 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
