[jboss-jira] [JBoss JIRA] (WFLY-13686) Deadlock on Wildfly startup

[K G (Jira)]

K G created WFLY-13686:
--------------------------

             Summary: Deadlock on Wildfly startup
                 Key: WFLY-13686
                 URL: https://issues.redhat.com/browse/WFLY-13686
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 20.0.1.Final
            Reporter: K G
            Assignee: Cheng Fang


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



--
This message was sent by Atlassian Jira
(v7.13.8#713008)