History cleanup: what process models get deleted?

Camunda 7 Topics Discussion & Questions
1

Hello,

I have two SpringBoot based process applications (each having a camunda engine inside) working with the same Camunda DB. One application has the process model ProcessA (and the corresponding Java code), the other has the process model ProcessB (and the corresponding Java code). Both applications are configured with deploymentAware=true.

Both applications have the cleanup parameters set.

My question is: Does each application clean up only “its own” process instances? Or does each application work with the whole database?

In other words: Will application A delete only the instances of ProcessA? Or will it also delete instances of ProcessB?

I could not find the answer in the docs.

Thank you for any clue on this!

2

Hello @fml2 ,

as history cleanup is not bound to a process application, both process engines will do the cleanup for all the process instances. This is because - as there is no relation to a process application - the history cleanup of each engine is not deployment-aware.

Jonathan

3 Likes
3

@jonathan.lukas,

thank you for the information! So, if I understand you correctly, it should work as follows:

  1. Both engines produce jobs of type “cleanup” that are scheduled according to the configuration of the engine (the settings – e.g. the cleanup time window – might be set to different values in the applications).
  2. When such a job is due, a job executor of one of the applications picks it up and executes it. It is not deterministic which job executor (application A or B) it will be.
  3. The job is executed according to the cleanup settings of the application whose job executor is performing the cleanup, i.e. how the cleanup time for process instances is calculated etc.
  4. The job removes instances of all process models stored in the Camunda DB (not just some of them).

Is that correct?

Thank you!

4

Hello @fml2 ,

  1. yes
  2. 90% sure. I would have to try out. It could be that the engine creating the job will try to assign and execute it on its own.
  3. yes
  4. yes

Our recommendation would be to coordinate history cleanup when running in a heterogenous cluster. If you have resources spare, you could even attach another engine that only exists for history cleanup (so no other engine is bothered with this). Here, you should keep an eye on database performance, as history cleanup costs some resources.

Jonathan

3 Likes
5

This is a very good idea, I’ll discuss it in our group. Thank you!

2 Likes
6

Hello @fml2 ,

additional information: Here is also a piece fo documentation that I got from at colleague:

Jonathan

1 Like
7

@jonathan.lukas , thank you for the link. I’ve already seen that, but the section does not tell anything about the cleanup behaviour wrt. the “deploymentAware” option. I think, the docs should spend some words on that.

1 Like