Hi Team,
Its quite awesome discussion to easy the tomcat as proc
I will say it's background compatible since then we added background active
element
StartStop both are in the hand of separate module
Spring Boot is already doing this as tomcat working as in background so it
will boost tomcat will gain the full moment of both are added
Regards
Koti
On Fri, 28 Apr 2023, 15:25 Rémy Maucherat, <r...@apache.org> wrote:
> 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
>
>
