With Camunda 7.6.0 (and CamundaSpringBoot 2.1.0-SNAPSHOT) we sometimes get (unreproduceable) error sampled below.
camunda.bpm.history-level is set to FULL. We use Hikari pool over PostgreSQL on 9.6, auto-commit is off.
Any ideas how to fix it (except lowering history-level)?
org.camunda.bpm.engine.ProcessEngineException: ENGINE-03004 Exception while executing Database Operation ‘INSERT HistoricVariableInstanceEntity[244]’ with message ’
There is only one activity (CallActivity Type = BPMN) marked “async before” in our processes, but I cannot be sure if it is the place where error did occur. Will make users take exact notes of where the error(s) occur.
All other asyncs are “async after”.
User reported a new occurrence of the issue with the same sympthoms. Interestingly, it happened for the 1st user session after drop-create redeployment in a cluster (i.e. no other user actions); 4 processes running initiated from one user-started task.
There are some “async before” actions before the problem took place. However, the last two asyncronous actions in the flow before the problem one are “async after” (and there are more actions without async mark at all before the error occurred).
Do you suspect that changing “async before” to “async after” is an easy way to get rid of the problem manifestation? We do not see business reasons to insist on “async before” currently and can change all of them to “async after” in our processes.
You should configure your process engine to use the StrongUUIDGenerator as documented here. There is also the reason, why the default generator shouldn’t be used in production, only for testing.
The newest Spring Boot starter release (2.1.0, released yesterday) allows you to customize the ID generators by specifying the property ‘camunda.bpm.id-generator=strong’ to use the StrongUUIDGenerator.
I just run into the same error (though on Camunda version 7.10) and solved it by changing the async before flag into async after on the start event.
Could you help me understand why this is an issue? I intended to use the async before on the start event because I expected a sub-process event to occur within milliseconds after instance creation and to ensure that the corresponding message can be correlated.