On Fri, Apr 28, 2023 at 9:02 AM Romain Manni-Bucau
<rmannibu...@gmail.com> wrote:
>
> Le ven. 28 avr. 2023 à 08:36, Rémy Maucherat <r...@apache.org> a écrit :
>
> > 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.
> >
>
> Still in the spirit of being "stable" in terms of threads and avoiding to
> create instances per components (which makes the machine under stress, in
> particular when combined with colocalised deployments - k8s style or just
> multiple processes locally.
> The destroy usage I saw was mainly to push (broadcast) metrics captured
> between stop and destroy by valves - but can ack it is a bit particular so
> can not need something specific.
We are talking about a Server.stop/start here, this is a very
expensive process (TLS configs, and so on), and I don't understand why
it would be a good idea to allow background tasks of subcomponents to
keep running.
> That said I'm not sure it fixes the spring-boot issue at all.
Remy
>
> >
> > 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
