8:06 p.m.
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.
--
James R. Perkins
Red Hat JBoss Middleware
9:07 p.m.
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
9:22 p.m.
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
9:33 p.m.
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
11:28 p.m.
On 09/19/2013 06:07 PM, David M. Lloyd 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.
Hmm... ...maybe my theory on what is happening is wrong then. I'll have
to debug it a bit more. That makes sense what you're saying though.
--
James R. Perkins
Red Hat JBoss Middleware
3869
days inactive
3869
days old
4 comments
3 participants
participants (3)
-
David M. Lloyd -
James R. Perkins -
Jason Greene