Update Camunda to v7.20.0 #190
Conversation
wcgunter
commented
Nov 6, 2023
•
wcgunter
commented
- Updates Camunda to v7.20.0
- Updates Tomcat to 9.0.75
- Removed manual process log cleanup to allow Camunda to efficiently decide when to remove old information. (HistoryCleanupDaemon has been renamed and now only cleans up ElasticSearch and worker logs every 8 hours
…s to "false" to support processes with "historyTimeToLive" set to false.
| @@ -5,6 +5,7 @@ | |||
| <bean id="processEngineConfiguration" class="org.camunda.bpm.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration"> | |||
|
|
|||
| <property name="history" value="activity" /> | |||
| <property name="enforceHistoryTimeToLive" value="false" /> | |||
There was a problem hiding this comment.
this is only temporary right?
There was a problem hiding this comment.
Yep! This allows the existing bpmn files to appear / be used / run. We just need to decide whether to enforce the "enforceHistoryTimeToLive" value in the bpmn files to not be null or to continue letting them be null (which might cause issues with clearing out historical data)
There was a problem hiding this comment.
I'm not really in the loop here, but from the perspective of other projects, history cleanup needs to work, and they will adopt the latest CWS at some point (hopefully). Is this value needed due to the upgrade to Camunda 7.20.0? And what's the plan to roll it back at some point? Thanks!
There was a problem hiding this comment.
Yes, this value is required now in Camunda 7.20 (see reasoning here: https://docs.camunda.org/manual/7.20/update/minor/719-to-720/#enforce-history-time-to-live). I think we are still deciding on what we want to do here because if we keep this flag as false here, it will keep the current behavior as is.
There was a problem hiding this comment.
Thanks. Why not just set enforceHistoryTimeToLive to "true" though? Per the Camunda article you linked above, projects will run into trouble if they don't start cleaning up history on day one. Since the other CWS settings don't have the history level turned completely off, this means that the default CWS will indeed run into trouble. For those reasons, I would think this should be "true". Does that make sense?
There was a problem hiding this comment.
We're probably going to end up reverting this change before we merge this in. The only reason it is set to false currently in the PR is because all of the testing & example models currently have "historyTimeToLive" set to null which prevents the models from being loaded by the engine at all.
I definitely agree that when we merge the PR in (at a point in the future when I've been able to iron out the issues with the automated testing) that this flag should be set to true - we'll just have to decide how to mitigate any issues with projects that have models that have a null value for their timetolive (whether thats just adding a step in our migration guide to have everyone update any out-of-compliance models or create a script that can do that for them).
There was a problem hiding this comment.
Thanks for the explanation, and that approach sounds good to me!
There was a problem hiding this comment.
@galenatjpl We are going to enforce that all models define the historyTimeToLive for CWS 2.6+.
Like this:
<bpmn:process id="external_pwd" name="external_pwd" isExecutable="true" camunda:historyTimeToLive="30">
In number of days.
…meToLive=false property
|
Hi @RonnyFrayRegato ! |
cws-service/src/main/java/jpl/cws/console/ElasticAndWorkerCleanupDaemon.java
Outdated
Show resolved
Hide resolved
