все сталкивались

обычная история

ну стандартная ошибка камунды когда параллельные ветви камунды выполняют одновременно работу и одна успела а вторая нет... ну и идет откат транзакции

никакой проблемы не вызывает кроме остановки процесса на время лока шага

А есть гайды, как с ней бороться?
Или бесполезно и она будет вылезать всё равно и тут только ретраи помогут?

меньше запускать паралельных процессов

когда таски идут последовательно вероятность такого резко падает на порядки

Ну вот у нас получилось поймать на схеме, состоящей из трёх последовательных шагов

Всем привет! Коллеги помогите советом)

Борюсь со следующей проблемой, после добавления схемы деплоя процессов в
processes.xml и декоратора EnableProcessApplication в cockpit пропал раздел Variables в запущенном инстансе.
Никто не сталкивался с такой проблемой, или это нормальное поведение?

P.S. Поподробнее почитал, данный функционал не входит в community версию?

Да вроде входит

А если назад убрать - все вернётся?

Да

Добрый день, нужна помощь по архитектуре приложения.
Camunda используется как оркестратор. В текущей реализации есть 2 приложения, как объяснили индусы, что первый это engine, а другой это админка для этого engine (cock pit). Оба смотрят в одну и туже БД. Периодически у нас валят ошибки Class not found, устранил их только дублированием класса с engine в приложение админки, боюсь что в будущем будут проблемы когда будут добавляться новые классы, и возникнет необходимость дублировать код в оба приложения.
Есть ли смысл держать оба приложения ?
Сколько памяти нужно для одного приложения (запущенных экземпляров около 70к) ?
Буду благодарен за ссылки на описания Camunda как оркестратора/

Всем привет! Кто-нибудь сталкивался с проблемой, что кокпит перестаёт переменные процесса показывать?

> Периодически у нас валят ошибки Class not found

Какие классы не находятся -- классы делегатов или другие?

Делегаты

deployment-aware у Вас проставлен?

Нет

В Камунде с кокпитом какие-то определения процессов есть?

Вариант решения:

1. В Камунде с кокпитом кладете starter BPMNs.
2. Starter BPMNs -- это схемы процессов, которые вызывают процесс (содержат только call activity).
3. Вызываемые процессы находятся во второй Камунде.
4. Во второй Камунде хранятся схемы вызываемых процессов и соотв. делегаты.
5. В обоих Камундах проставлен deployment-aware (см. https://docs.camunda.org/manual/7.15/user-guide/process-engine/the-job-executor/#job-execution-in-heterogeneous-clusters ).
6. Чтобы это работало, в вызываемых процессах async-before должен быть проставлен везде (во всех активностях вызываемого процесса).

Тогда ошибки, что не находятся делегаты должны исчезнуть.