WildFly 21+ EJB Invocation From Web Module Causes Deployment Timeout

[Josh Fisher]

I am currently upgrading from WildFly 20.0.1.Final to 22.0.0.Final and have encountered an issue with EAR deployments timing out when during initialization a web module invokes an EJB in a previously initialized module but there is at least one other EJB module not yet initialized that contains startup singleton beans.

I created this project to illustrate the issue https://github.com/jfisherdev/wf-ejbstartup-lock

and it has more information describing it in the README.md, but I will include the key points here for convenience.

This requires an EAR application that meets the following criteria:

• It has at least two <ejb> modules and at least one <web> module
• The application.xml has <initialize-in-order>true</initialize-in-order> and the module order is such that the initialization of the web module(s) happens after at least one EJB module and before another EJB module, which has at least one singleton bean annotated with @javax.ejb.Startup.
• The web module invokes an EJB in a previously initialized module during its initialization, such as from a Servlet#init() or ServletContextListener#contextInitialized() method.

In WildFly 20 and earlier, the application will deploy successfully; however, in WildFly 21+ the invocation during web module initialization will be stuck awaiting a condition in org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation until the deployment times out after the period defined by jboss.as.management.blocking.timeout system property.

This seems to be specifically an issue with invocations from web modules with the EAR, as the same call to a previously initialized EJB module in the same EAR from a startup singleton bean in a different module in its @PostConstruct annotated method works.

Ideally sensible module ordering and application structure avoid this, but that may not always be the case.

In any case, it would be good to know why this started happening since WildFly 21 and if an issue should be filed about it.

Thank you.

[Brian Stansberry]

I suspect this is due to the fix for https://issues.redhat.com/browse/WFLY-13515.  My guess is both EJB modules in your EAR have @Startup singletons. The WFLY-13515 fix changed the point when the total number of such singletons is calculated, with effect that the ejb module A now knows about the existence of the singleton in ejb module B even before it is installed, and blocks calls until it is initialized. Before I think it's likely there was a period where A had initialized, knew about its own singleton count (and the count from any other ejb module that might have preceded it) and then would accept invocations once those had initialized. So at that moment the web module could invoke. Then when module B started deploying, the total singleton count would be increased and now invocations would again be blocke until B's singletons were initialized.