Le ven. 28 avr. 2023 à 11:55, Rémy Maucherat <r...@apache.org> a écrit :
> 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.
>
Server means more or less all the subgraph, it is not about leaking tasks
but dont break the backward compat since today it is allowed.
>
> > 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
>
>
