[wildfly-dev] Running Batch During Undeploy

David M. Lloyd david.lloyd at redhat.com
Thu Sep 19 21:33:06 EDT 2013


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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
- DML


More information about the wildfly-dev mailing list