DK
Суспенд рукой можно включить
Size: a a a
2018 December 24
E
Или инцидент в суспенд переводит?
да, ты прав, в инцидент, как в этом случае уйти в нормальную работу?
DK
Resolve incident метод есть
DK
Или рукой нажать в кокпите
AK
а можно вопрос по нотации BPMN - правильно ли (с точки зрения нотации) рисовать несколько output Transition-ов из User Task - или надо ставить Exclusive Gateway и уже из нее рисовать варианты выхода?
SN
Там называется мудро в крепите. Добавить ещё одну попытку обработки. По умолчанию инцедент после 3 неудачных попыток возникает
DK
а можно вопрос по нотации BPMN - правильно ли (с точки зрения нотации) рисовать несколько output Transition-ов из User Task - или надо ставить Exclusive Gateway и уже из нее рисовать варианты выхода?
Формально можно, но это плохой стиль
SN
а можно вопрос по нотации BPMN - правильно ли (с точки зрения нотации) рисовать несколько output Transition-ов из User Task - или надо ставить Exclusive Gateway и уже из нее рисовать варианты выхода?
Неправильно. По умолчанию ставится параллельный шлюз тогда
AK
Спасибо!
SN
Если без шлюза и хотите разные варианты то можете использовать conditional flow
E
Resolve incident метод есть
может есть режим, чтобы отключить систему инцидентов, или это обязательная составляющая?
DK
А что делать процессу, если он упал?
DK
Ретраи можно навернуть
AK
кстати про 1000 TPS и что "это не про Camunda" - я бы не был столь категоричен. Все зависит от условий: Мы когда проводили сравнительное тестрование Camunda & Flowable - то получали 500 TPS на кластере из 3ех нод по 2 core + 8 core на DB (postgresql)
AK
а если отключить сохранение исторических таблиц.... то уходили и на 1500 TPS на той же конфигурации
AK
в целом у нас узким местом оказался IOPS на диске базы
AK
ну и важно понимать - что на любом safe point происходит сохранение а потом восстановление состояния процесса
RT
кстати про 1000 TPS и что "это не про Camunda" - я бы не был столь категоричен. Все зависит от условий: Мы когда проводили сравнительное тестрование Camunda & Flowable - то получали 500 TPS на кластере из 3ех нод по 2 core + 8 core на DB (postgresql)
да, многое зависит как от структуры самого процесса так и от настроек истории и СУБД
AK
а если отключить сохранение исторических таблиц.... то уходили и на 1500 TPS на той же конфигурации
А процесс был "hello world"?