org.wildfly.io.max-threads capability is subject to race conditions.  The capability is installed and available before an io worker is actually added.  A worker might typically be added more shortly after to prevent issues.  But depending upon timing, it's possible that something may check the max thread count provided from this capability before any actual worker has been added.   Thus, something in start up could read a 0 value inconsistently instead of the actual io worker max threads (or possibly some value in between if there are multiple io workers to contribute to that total value).

An impacted example would be the default EJB slsb that is deriving size from-worker-pools:

                    <strict-max-pool name="slsb-strict-max-pool" derive-size="from-worker-pools" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/> 

So sometimes it may see the actual io worker thread max and size to that value or it may see 0 and fall through to derive size from cpu counts instead here.  This particular bad result can occur if org.wildfly.extension.io.WorkerAdd.performRuntime happens to occur after org.jboss.as.ejb3.component.pool.StrictMaxPoolConfigService.<init> for any reason.

It looks like this has been slightly race susceptible for a while but it became notably worse after https://github.com/wildfly/wildfly-core/commit/c16f103cb2057fb337bfac0b9be2debca8ec8802 and https://github.com/wildfly/wildfly-core/commit/083c7848daecdac98e0c4394213053cd99e0a242.  Prior to this, it looks like IOSubsystemAdd helped this race condition by starting the capability service in mode NEVER.