In the case of shared thread pools the solution is similar - you need a
dependency to clean up outstanding tasks. This should not be different
from undeploying an application which has in-flight EJB invocations.
On 09/19/2013 08:22 PM, Jason Greene wrote:
The problem with that is that we share pools with deployments since
otherwise with a hundred deployments you easily end up with thousands of threads.
On Sep 19, 2013, at 8:08 PM, "David M. Lloyd" <david.lloyd(a)redhat.com>
wrote:
> On 09/19/2013 07:06 PM, James R. Perkins wrote:
>> While doing some testing with batch we discovered somewhat of a corner
>> case in where you have submitted a batch job then decided to explicitly
>> undeploy the application or something triggers an undeploy. The batch
>> thread will continue to run which causes issues if the start on the
>> batch is called again. My theory is the old batch environment is being
>> used as it's still alive in the thread.
>>
>> This begs the question though what should happen if a batch job is
>> running and an undeploy is invoked? Should we fail the undeploy? Should
>> we kill all batch jobs (probably not ideal)? Luckily for us the spec
>> says... ...nothing.
>
> The service controlling the thread (pool?) will depend on the
> deployment. When the deployment is stopped, the thread pool is shut
> down and all executing threads are interrupted. The service then waits
> until the the thread pool terminates before completing the undeploy.
>
> The key is to make sure the thread pool service depends on the deployment.
>
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML