[
https://issues.jboss.org/browse/WFLY-3836?page=com.atlassian.jira.plugin....
]
Brian Stansberry resolved WFLY-3836.
------------------------------------
Fix Version/s: 16.0.0.Beta1
Assignee: Brian Stansberry (was: Jason Greene)
Resolution: Partially Completed
I'm resolving this as partially completed as there are a couple things that have been
done to mitigate this:
1) The suspend management op used with graceful shutdown can also be used independently
and should be used before non-shutdown/reload undeploy or redeploy. This is only
tangentially relevant as it does not result in interrupting ongoing work.
2) The WFCORE-1632 work will interrupt ongoing work during shutdown/reload. Whether it
would interrupt this particular scenario, I don't know, it depends on the details of
what threads are running the long-running tasks. The WFCORE-1632 interrupt requires a
shutdown or reload though, as it triggered by the termination of the thread pools, which
are not specific to a deployment.
Having deployment-specific services track what threads are executing tasks on the
service's behalf so they can interrupt them as part of service stop would be
theoretically better and would eliminate the need to shutdown/reload to get this behavior
but it would also be quite complex to implement and would carry a performance penalty from
the task tracking. So it's unlikely to happen.
Unable to undeploy an application when it is running long time EJB
calls.
-------------------------------------------------------------------------
Key: WFLY-3836
URL:
https://issues.jboss.org/browse/WFLY-3836
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 8.1.0.Final
Reporter: Dominik Pospisil
Assignee: Brian Stansberry
Priority: Major
Fix For: 16.0.0.Beta1
To update an application that is running, replace command from the management console is
used. Therefore, first, the application needs to undeploy.
After org.jboss.as.web.deployment.WebDeploymentService.doStop, ServerService Threads keep
in WAITING state waiting all active ejb invocation to finish:
"ServerService Thread Pool -- 116" prio=10 tid=0x00002b5cdce97000 nid=0x6d68 in
Object.wait() [0x00002b5d10d0b000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000005c5447f68> (a java.lang.Object)
at java.lang.Object.wait(Object.java:503)
at
org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory.shutdown(ShutDownInterceptorFactory.java:111)
- locked <0x00000005c5447f68> (a java.lang.Object)
at
org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.stop(StatelessSessionComponent.java:135)
at
org.jboss.as.ee.component.ComponentStartService$2.run(ComponentStartService.java:72)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Locked ownable synchronizers:
- <0x00000005ba6adf98> (a java.util.concurrent.ThreadPoolExecutor$Worker)
However, the application has some managed beans that do long time calls to a EJB method
using remote invocation. DC and HC "hang" before the EJB call finish.
JBoss could have a time out to the undeploy.
Version-Release number of selected component (if applicable):
JBoss EAP 6.1.1
Actual results:
The application does not undeploy intermittently.
DC and HC "hang" (they disconnect to each other) and it is necessary to restart
all Hosts.
Expected results:
After some time waiting, the undeploy is forced to finish.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)