-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
20.0.1.Final
-
None
-
-
Workaround Exists
-
On Wildfly startup there can be a deadlock related to ejb/singleton access and more specifically: StartupAwaitInterceptor and ContainerManagedConcurrencyInterceptor. This can happen when there is a too early client request (occurring during app startup) or a request caused by thread running in managed executor (that's what happened to me). A thread that is blocked by StartupAwaitInterceptor also holds a lock from ContainerManagedConcurrencyInterceptor and blocks other threads. This is related to the following pull request, link to the comment: https://github.com/wildfly/wildfly/pull/9009#issuecomment-656147415 .
I guess possible solution is to change interceptors ordering. Other possibility is to add "privileged" flag (see pull request for explanation) to threads from managed thread factory but in this case a too early client request could also cause a dealock.
Scenario of deadlock (description copied from pull request's comment):
- startup singleton A's initialization starts and completes successfully
- startup singleton B is initializing and during that it starts a task X via managedThreadExecutor
- X wants to access A and is blocked by StartupCountdown.await
- meanwhile B continues initializing and wants to access A but X already holds a lock on A (I can see ContainerManagedConcurrencyInterceptor.processInvocation in the tread dump) hence after 5000ms B's initialization fails as well as whole deployment
- is related to
-
WFLY-10879 Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
- Closed