[jboss-jira] [JBoss JIRA] (WFLY-3836) Unable to undeploy an application when it is running long time EJB calls.

[Brian Stansberry (Jira)]

     [ https://issues.jboss.org/browse/WFLY-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)