I noticed the behaviour that once I restart the tomcat server all my processes get deployed again. Thus every war file gets deployed again Incrementing the Version Counter of the process. So when I have version 1 and 2 deployed this leads after a restart to 4 deployments as both get redeployed. After some restarts and several processes the engine gets completely bloated with process definitions.
I noted that this happens only in case that the process definition has a version. In case i deploy without a version this does not happen.
In this case we see expected behavior, or to put it differently this use case is not supported. A new process deployment (and thus process version) is created whenever the most recent version is not the same as the version to be deployed. On startup, the deployments of your WAR files happen one after the other, so each deploys on top of the other and the check for duplicates does not apply.
thank you. This was indeed very helpful. I always thought that a process war file encapsulates JavaDelegates, Process Definitions, Forms etc. pp and each war file runs in some sort of its own ecosystem. No I see that this is not the case.
Are there any best practices for versioning the workflows? I mean, after 20+ versions with improvements and bug fixes and so on, it can be pretty hard to keep in mind that a change in the form or the Java Delegate Service tasks will not break anything in old deployments.
I always thought that a feature of camunda is that the process instances can be long running and I can slowly discontinue the old versions while new processes get started on the new versions. With this behaviour I think one must migrate all old instances in any case and immediately to avoid any flaws.