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