On Wed, Jul 31, 2019 at 8:40 AM Ingo Weiss <ingo(a)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(a)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
> > > 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)
> 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
> 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
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
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.
Manager, Senior Principal Software Engineer