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>
> 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
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.
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 :)