Size: a a a

Camunda BPM Group

2020 February 17

VC

Vladimir Chernovolov in Camunda BPM Group
Eugeny
А почему используется boundary event, а не catch event? Может ли таска из-за этого завершаться дважды?
Исторически так сложилось, что используем boundary event

"Может ли завершаться дважды ?" Это трудно словить с текущей реализацией - boundary event, нужно переделывать на catch event и смотреть, как поведет себя Camunda.

Теоретически не должно же быть разницы (?)
источник

E

Eugeny in Camunda BPM Group
Ну баундари принудительно завершает текущую activity, плюс, ресив таска (это же она?) может закончится и сама по себе, сразу же. Я понимаю, что это все врятли, и должно случится только что-нибудь одно, но все же - может попробовать кэтч ивент? Как то он там более правильным будет.

Баундари потдее, призваны прерывать исполнение таски по событию, что бы просто подождать события - есть кэтч ивенты, ИМХО
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
почему boundary должен прерывать что-то?
источник

VC

Vladimir Chernovolov in Camunda BPM Group
в данном случае таска Wait просто *wait state*, остановиться, ждать
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
boundary это ограниченный, interrupting это прерывающий
источник

E

Eugeny in Camunda BPM Group
Ruslan Kadyrbaev
boundary это ограниченный, interrupting это прерывающий
Согласен, был неправ. У нас просто подавляющее число boundary event'ов используются с interrupting = true
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
Vladimir Chernovolov
Есть процесс (см. рисунок выше), который останавливается на таске Wait и ждет таймера (в данном случае долгий интервал - дни).

В табличке act_hi_job_log до этого момента все ок - одна запись со статусом (job_state_) = 0 (created).
Ветка одна, нет параллельных веток до таски Wait.

Далее, срабатывает таймер через Х дней, и ветка процесса отрабатывает 2 раза.
В табличке act_hi_job_log - две записи, одна из которых со статусом = 2 (success),
другая - со статусом 1 (failure), и job_exception_msg_ = 'ENGINE-03005 Execution of 'DELETE TimerEntity[xxxxxx]' failed. Entity was updated by another transaction concurrently'.

Соот-но вторая ветка завершается неуспешно.

Но даже в этом случае выполняются таски Call service X, Call service Y и далее по ветке.

Конфиги Camunda - все по дефолту.
Причем данная ситуация достаточно редкая.

Подскажите, кто сталкивался с таким, в чем может быть причина срабатывания таймера более 1 раза,
что можно донастроить, чтобы ветка отрабатывала гарантированно 1 раз ?
(версия Camunda = 7.10, поднята в OpenShift, смасштабирована в 4 пода)
возможно две ноды начали обрабатывать это таймер одновременно, и одна наткнулась на concurrency
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
если никаких побочных эффектов нет (кроме записи в act_hi_job_log) - то тогда вроде нормально все) ну чисто логически
источник

VC

Vladimir Chernovolov in Camunda BPM Group
Ruslan Kadyrbaev
возможно две ноды начали обрабатывать это таймер одновременно, и одна наткнулась на concurrency
https://docs.camunda.org/manual/7.10/user-guide/process-engine/the-job-executor/#job-acquisition

а не должны джобы лочится, если кто-то начал его исполнять ?
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
ну вообще есть две политики блокировок общепринятых - пессимистичная (сразу лок) и оптимистичная (по факту возникновения exception будет)
источник

VC

Vladimir Chernovolov in Camunda BPM Group
Ruslan Kadyrbaev
если никаких побочных эффектов нет (кроме записи в act_hi_job_log) - то тогда вроде нормально все) ну чисто логически
есть, ветка исполняется, таски выполняются
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
:) тогда еще навскидку: приходит два события, схема имеет баг
источник

R

Ruslan Kadyrbaev in Camunda BPM Group
хотя нет, тут чистый concurrency (один и тот же TimerEntity)
источник

VC

Vladimir Chernovolov in Camunda BPM Group
Ruslan Kadyrbaev
хотя нет, тут чистый concurrency (один и тот же TimerEntity)
ну похоже на то, что таймер стартует дважды, причем достаточно редко такое происходит

а как такое можно полечить ?
источник

DK

Denis Kotov in Camunda BPM Group
Хмл покажите
источник

DK

Denis Kotov in Camunda BPM Group
Из активности всегда надо бы иметь выходящий поток
источник

DK

Denis Kotov in Camunda BPM Group
Который не через атачед эвент идет
источник

VC

Vladimir Chernovolov in Camunda BPM Group
Denis Kotov
Хмл покажите
скинул, в личку
источник

СХ

Саддам Хусейн... in Camunda BPM Group
а кто-нибудь знает порядок цен на камунду энтерпрайз?
источник

DK

Denis Kotov in Camunda BPM Group
От 70к зелени в год
источник