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)