Deployment-Aware Job Executor

Camunda 7 Topics Discussion & Questions
1

Hi everybody,
perhaps somebody can explain me how the Deployment-Awareness is implemented for the job executor. At the moment, we use a self made Docker Image (base on a Tomcat with a shared engine) and we think about clustering the Docker Containers:
But lets say Docker container one (DC1) and Docker container two (DC2) has the same access to the database and same version of the processes, started by a message at a Queue-Listener. Now I start a blue/green deployment, so stop DC1, deploy new Process and restart DC1. At this moment only there is a new version V2 at DC1.
When DC1 catches the message from the Queue, process some tasks and commits. Now how is guaranteed, the now the job Executor of DC2 does not continue with the task? What is the ID of the awareness? The IP or hostname would be problem, because in the Docker world they will change quiete often…

2

Hi Timo,

If you run a deployment-aware job executor, then the job executor only picks up deployments that are registered with the process engine.

How registration happens:

  • Whenever a deployment is made via API
  • Whenever a process application is (re-)deployed, it registers all deployments it makes and resumes
  • Manual registration via ManagementService#registerDeploymentForJobExecutor
  • Registrations are not persisted

So in order to answer your questions, we would have to look at when these things happen, which depends on how you deploy your processes.

Cheers,
Thorben

2 Likes
3

Hi Thorben,

thanks… at the moment we just do a redeployment of the whole application with the process-files inside. Do you know where the registration is persisted? We have two mainly undependent engines running, just sharing the database, so there has to be some information persisted, which engine might run which process, hasn’t there?

4

The registration itself it not persisted.

What is persisted is which job belongs to which deployment. This together with the registrations at runtime allow the job executor to decide for which jobs to poll.

If I understand you correctly, you have different process applications deployed in these containers. In this case, registrations are automatically made whenever you start the container. In effect, each job executor will pick up only those jobs that belong to the deployments for which there are process applications deployed on their respective container.

Cheers,
Thorben

2 Likes
5

@thorben interesting to know the exact behavior. I do not remember finding this information in the documentation.

Was there a specific reason, why the engine does not register for all of its past deployments, for example based on the “source name” of the deployment?

6

Hi @RobertR,

I think there is no other obvious criterion by which to auto-resume deployments that would not produce false positives. For example the source of a deployment only tells us if it comes from some process application or not, but not from which. If the name of the application was available to use for this, there could be issues around changing application names, etc.

Cheers,
Thorben

7