[wildfly-dev] Allowing disabling of 'graceful startup'

[Brian Stansberry]

On Wed, Jul 31, 2019 at 8:40 AM Ingo Weiss <ingo at redhat.com> wrote:

> On 2019-07-30 17:40:52-0500, Brian Stansberry wrote:
> > On Tue, Jul 30, 2019 at 12:59 AM Ingo Weiss <ingo at redhat.com> wrote:
> >
> > > Hi Brian, thanks for looking into this.
> > >
> > > On 2019-07-29 12:17:36-0500, Brian Stansberry wrote:
> > > > The Question
> > > >
> > > > Question is whether to
> > > >
> > > > a) have an overall config switch to disable graceful startup across
> the
> > > > board (e.g. a new value for the --start-mode cmd line param passed to
> > > > standalone.sh)
> > >
> > > I think this the better solution based on your pros. Having this
> > > limited to only HTTP(S) requests makes it very limiting and ends up
> > > not being sufficient in some cases, as you described.
> > >
> > > Do you think it would be possible to make this configurable per
> > > subsystem as well?
> > >
> > > For some subsystems, like Undertow and EJB, you may want to use as
> > > soon as they become available to reach out other systems or even call
> > > a servlet on another deployment that has already started, this a case
> > > I've seen before, while others, like Messaging, you may want to wait
> > > for other subsystem, like JCA, to come up first. Does it make sense?
> > >
> >
> > If I understand you correctly, instead of my a) a global flag, or my b)
> an
> > undertow flag, there would be several b)s. One to tell undertow to let
> > requests through, one to tell EJB to let requests through,, one to tell
> > messaging to let requests through (although that one's theoretical as
> > messaging doesn't have graceful startup/shutdown anyway.)  Probably one
> for
> > every subsystem that does anything related to graceful. The user then
> > toggles the ones they want for their app. They'd have to know which they
> > want.
>
> That's what I was thinking.
>
> > That would be a quite big increase in scope.
>
> Yeah, it was an increase in scope indeed, but I think it might end up
> being a better fit for users.
>
> It could surely be a multiple-phase approach. We start with a, see how
> it goes, then move to b * no_of_possible_subsystems.
>

That's true; a global switch doesn't preclude something more fine-grained
in the future.

>
> > Not sure it's worth it, but it's something to think about while I'm on
> PTO.
> > :)
>
> Enjoy and don't think about this. That's bad for you :)
>

Thanks. Probably won't think too much. :) But this is a not small or
trivial thing, nor something huge like dealing with javax.* being renamed
to jakarta.* so it's the kind of thing I sometimes find relaxing to think
about when I'm chilling out.

> --
> Ingo Weiss
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20190731/f2d50557/attachment.html