[jboss-jira] [JBoss JIRA] (WFCORE-3185) Run parallel boot tasks in coarser grained chunks

[ https://issues.jboss.org/browse/WFCORE-3185?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3185 at 4/23/19 5:30 PM: ------------------------------------------------------------------- It looks like the problem we were seeing with this in full was due to the fact that server (as opposed to HC) boot will not work properly with a deployment if parallel boot is disabled. This change just exposes it by making it easier to disable parallel boot, i.e. by running with only a single CPU. It's always been possible to turn it off though, by setting system property org.jboss.server.bootstrap.maxThreads. (Ancient history behind that -- the property controls the size of the MSC pool and setting it was seen as an indication that careful control of threads was wanted; e.g. in a constrained environment.) The problem is this: https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java... and then this: https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java... Those lines are *adding steps*. Which, with parallel boot get added to a special ParallelBootOperationContext, which runs them as part of the set of ops for 1 subsystem (before this fix) or a set of subsystems (with this PR). Either way, they run before boot proceeds past the subsystem ops and on to deployment ops. But without parallel boot, those ops get added to the overall list of ops, and that means they happen *after* ops like /deployment=foo:add run. Which means the deployment can be getting installed before all the subsystem work is done. In this case the subsystem work is adding a DUP that ensures the deployment has access to certain modules. There's nothing wrong with what the subsystem is doing there. It's a very common pattern to add steps to execute later. There are two solutions I see here: 1) Execute ops after the subsystem ones separately; i.e. break boot up even further, from the current two operations to three. 2) Tweak parallel boot so it basically always runs in a server, which is pretty simple. It's pretty clear boot hasn't worked properly without parallel boot turned on for a long time. [~smarlow] FYI, as I figure you might be curious. :) was (Author: brian.stansberry): It looks like the problem we were seeing with this in full was due to the fact that server (as opposed to HC) boot will not work properly with a deployment if parallel boot is disabled. This change just exposes it by making it easier to disable parallel boot, i.e. by running with only a single CPU. It's always been possible to turn it off though, by setting system property org.jboss.server.bootstrap.maxThreads. (Ancient history behind that -- the property controls the size of the MSC pool and setting it was seen as an indication that careful control of threads was wanted; e.g. in a constrained environment.) The problem is this: https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java... and then this: https://github.com/wildfly/wildfly/blob/master/iiop-openjdk/src/main/java... Those lines are *adding steps*. Which, with parallel boot get added to a special ParallelBootOperationContext, which runs them as part of the set of ops for 1 subsystem (before this fix) or a set of subsystems (with this PR). Either way, they run before boot proceeds past the subsystem ops and on to deployment ops. But without parallel boot, those ops get added to the list of ops, and that means they happen *after* ops like /deployment=foo:add run. Which means the deployment can be getting installed before all the subsystem work is done. In this case the subsystem work is adding a DUP that ensures the deployment has access to certain modules. There's nothing wrong with what the subsystem is doing there. It's a very common pattern to add steps to execute later. There are two solutions I see here: 1) Execute ops after the subsystem ones separately; i.e. break boot up even further, from the current two operations to three. 2) Tweak parallel boot so it basically always runs in a server, which is pretty simple. It's pretty clear boot hasn't worked properly without parallel boot turned on for a long time. [~smarlow] FYI, as I figure you might be curious. :) -- This message was sent by Atlassian Jira (v7.12.1#712002)