after log inspection i found the following exception logging
2020-03-04 11:51:52.738 [WARN ] [pool-2-thread-1] o.c.b.e.jobexecutor.logWarn:146 [] ENGINE-14006 Exception while executing job 51559: OptimisticLockingException. To see the full stacktrace set logging level to DEBUG.
...
2020-03-04 11:54:55.360 [WARN ] [pool-2-thread-3] o.c.b.e.jobexecutor.logWarn:146 [] ENGINE-14006 Exception while executing job 51559: OptimisticLockingException. To see the full stacktrace set logging level to DEBUG.
...
2020-03-04 12:02:10.155 [WARN ] [pool-2-thread-2] o.c.b.e.jobexecutor.logWarn:146 [] ENGINE-14006 Exception while executing job 51559: OptimisticLockingException. To see the full stacktrace set logging level to DEBUG.
→ this is continued for more than one hour. After that the flow is back on “normal”
the excecuted java class is doing variable changes like this
Problem 1:
for me it is unclear why the exception is happening. my assumption is in the moment: The postgress DB was not available for some time and therefore the state could not be updated by camunda inside the DB.
but i dont know how to check if this is a correct assumption?! or is it an error in the flow?
Problem 2
The red part in the flow executes a code, that makes a REST call. This part should never be called more than 1 time. how do i make sure, that this never is repeated? i would prefer to have an abortion of the flow (with an incident or similar…)
the problem happened a second time and i can rule out problems on the DB side.
other ideas:
we have some plugins for cockpits. they are doing read only request to the DB. maybe it is possible to have some kind of locking here? seems very unlikely
the only other solution would be to write a own implementation: Every service task executed is stored in a separate DB and checked if a double execution happens. but this sounds like a lot of overhead for something that the workflow engine should do for me?!
i have an idea what could lead to random problems.
in our code we clear sometimes the ThreadContext. And i recognized that the new camunda version uses the threadcontext too (we upgraded last week to 7.12…)
maybe there are problems created by this in the transaction handling?
what be nice to her something form a camunda developer about this…
I had a similar issue with the same WARNING message. What happened to me is that my timer kicked out but hanging. Then my process instance just stuck. Any ideas?
BTW, how to set the logging level to DEBUG at runtime? My version is 7.17.0-alpha4.