Hello everybody,
like many of you realized (maybe much earlier ) historyTimeToLive is defaulted with null and ignored. So we already configured our processes with config param camunda.historyTimeToLive and of course configured the historyService itself and all is fine. Well. For process instances.
Only now did I realize: we heaped up millions of decision instances, that should better be cleaned up. And this seems to be a problem. What did I try?
- camunda.decisions.historyTimeToLive (or a param like this) does not exist
using placeholder ${camunda.historyTimeToLive} in the param field of a decision doesn’t work, because placeholders are not numeric. - putting that into a variable HashMap named envparam and using placeholder #envparam.get(“camunda.historyTimeToLive” … ist still not numeric, so doesn’t work
- Trying to update a just-deployed decision with a historyTimeToLive … for the moment I cancelled that, because it seems way to complicated for me. From what I read, EventListener to PostDeployEvent would be a possible solution
Anyways, my questions out to you - did I just miss something about the property placeholder solution?
- anybody had the same problem and a suggestion to solve it?
- Question to Camunda Gurus: The config is already quite impressive what it offers for params but could it be a solution, to just add a config param like you did for cleanUp batchOperations and even CleanUp itself?
Some technical detail: we are running several Camunda processes on Camunda 7.16 using a shared database (we spread a very complex process on 3 engines), all processes are deployment-aware, the 3 engines are SpringBootApplications running on OpenShift. HistoryTimeToLive should better be env