Deploying Workflow While Current Processes Are Running

Camunda 7 Topics Discussion & Questions
1

Our environment: Red Hat 6.X EL, WildFly 10, Camunda 7.5.3-ee.

Can you deploy/update/remove a process definition while processes from a previous version are still running?

Our deployment is a war file from Eclipse Mars with the Camunda Plugin. Deployment is through the WildFly console.

2

Hi @mppfor_manu,
removing process definition won’t be the thing you want to do, but you can deploy a new version and then migrate existing process instances to a new version. You can read more about here

https://docs.camunda.org/manual/7.5/user-guide/process-engine/process-versioning/

Cheers,
Askar

3

Thank you for the reply.

Can you clarify what you mean by “removing process definition won’t be the thing you want to do”? Are you saying that you should not attempt to delete process definitions for processes that have already run or are currently running?

4

Hi @mppfor_manu,

you can do that, but it will cascade on running process instances by default as I remember and this feature only available in 7.6.

https://docs.camunda.org/manual/latest/reference/rest/process-definition/delete-process-definition/

Cheers,
Askar.

5

Environment: Red Hat EL 6.7, Camunda 7.5.3-ee, WildFly 10

We did some tests wherein we fired a series of REST requests which started a specific job whose only activity was to print the value of a variable (representing the number of loops executed) we inserted in the REST message payload. This allowed us to track individual process instance execution.

We started the REST request loop and then redeployed the process while the messages were still being sent to the REST interface. Camunda dropped a significant number of these requests during redeployment because it could not find the required class which was part of the process deployment.

I would have expected Camunda to queue or hold these requests whilst the redeployment was taking place. Instead it simply discarded the requests. Are we doing something wrong?

6

Hi @mppfor_manu,

may I ask you how you performed redeployment?

Cheers,
Askar.

7

We used the WildFly 10 management GUI “replace” option, selected the file from the local workstation, and let WildFly do the rest.

8

@mppfor_manu,

well, when you use “replace” I would assume what happens in wildfly in reality is “delete” and then “install”. Which explains why your requests are bounced. Would it be an option for you just to deploy a new version(another .war name has to be provided I assume), migrate running process instances, and then remove old deployment.

Cheers,
Askar

9

Let me see if I understand what you are saying. You’re saying that the proper method of “replacing” current process code with updated process code is as follows:

  1. Update the process code

  2. Assign a new version to that updated code

  3. Build the code

  4. Deploy the code as a “new” deployment

  5. Allow existing processes running against the old version to complete

  6. Check to make sure that new process starts use the new version of the code (which I believe is Camunda’s default behavior)

  7. Remove the old deployment from the server, leaving only the new version in its place.

What are the consequences of removing the old version after all processes using it have completed?

If the issue with “replacing” process code is that a class that is included in the code is temporarily missing, could that class be packaged as a module in WildFly so that it was globally available all the time? Then, the deployment build would set a target of “provided” for that class in the process code POM file.

Michael

10

I have tried the preceding deployment process on Camunda 7.6.0-alpha5-ee and the associated WildFly 10.1.0 instance.

We still get failures if we attempt to add a process of the same name for which we’ve changed the version number in the Maven pom file.

This means that we cannot update a process of the same name unless we completely remove the existing process deployment first. Any attempt to add the updated process to the WildFly as a “new” deployment fails and corrupts the existing deployment. Note that the only difference between the first and second deployments was the version number. To ensure that there was some sort of “checksum clash” where both deployments appeared to be identical, I tried a third deployment, adding some comments to a service task. I built the process and attempted to deploy it, but this resulted in the exact same corruption as before.

The only way to update the process is to remove the original process first and then you can deploy the update. This isn’t going to work for reasons you already know about.

Attached are relevant log entries. Note that around half way down I attempt to start the “original” process after the failed deployment (which did not roll back properly). You can see that it is throwing errors.

PrintCounter_Camunda_7.6.0-alpha5-ee_WildFly-10.1.0.log (40.6 KB)