Details
-
Bug Report
-
Resolution: Won't Fix
-
L3 - Default
-
None
-
None
-
None
Description
Environment (Required on creation):
Run CAMUNDA in Kubernetes
Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):
During the migration of the CAMUNDA microservice and the subsequent start, it was revealed that there is a problem of starting the hearths when the hearths rise in parallel, i.e. the scale from 0 to 2 pods. The analysis showed that with the start, the waits in the database on the ACT_GE_PROPERTY.
The problem query itself that open and lock the table:
SELECT VALUE_ FROM ACT_GE_PROPERTY WHERE NAME_ = 'deployment.lock' for update
Steps to reproduce (Required on creation):
Scale pods to 0, then scale to 2.
It turns out like this - one pod up and become 2/2, the second pod 1/2 and then rebut constantly.
Observed Behavior (Required on creation):
The ACT_GE_PROPERTY table is locked.
Expected behavior (Required on creation):
The ACT_GE_PROPERTY table lock does not occur. And the scale from 0 to 2 occurs without problems.
Root Cause (Required on prioritization):
Solution Ideas (Optional):
Use the following query:
UPDATE ACT_GE_PROPERTY SET BLA_BLA_BLA WHERE NAME_ = 'deployment.lock'