Aha, this give me a clue as to what might be happening.
We are running our application, including the Camunda engine, using virtual machines on Amazon Web Services. In our QA environment, we often bring down deployed instances and then bring up new instances whenever we deploy new code.
Also, we haven’t touched the jobExecutorDeploymentAware setting, so this is true by default (as you noted).
So, could it be possible that the following is happening?
- We have a virtual machine up in AWS.
- We deploy a workflow model to this machine.
- Instances of this model run fine.
- We bring down this machine and bring up a new one.
- Now when we try to run instances of this same deployment, the async service tasks don’t run because of the deployment aware setting. This is a different machine, so these jobs won’t run on this machine because they are associated with the deployment on the machine which has been brought down?
- We observe that if we deploy the exact same model, then instances from the new model run fine, because now the deployment is associated with this new virtual machine.
Does this seem to you that this is the source of our problem? If so, then I guess we need to set jobExecutorDeploymentAware to false.
Can you tell me exactly how nodes are identified in a deployment aware configuration? Is it based on the IP address of the machine or is some other id used?