Тогда разумнее разнести не только по движкам, но и по БД. У вас общая бд. На сколько я понимаю, схема тоже общая. И ваши процессы лежат по факту в одной таблице. И джобы в одной таблице. Соответственно и движки читают из одной "очереди". А вот листенеры в разных classpath

Может я и не прав. Код с мобилки смотрел. Но со стороны выглядит так

> Соответственно и движки читают из одной "очереди".

Правильно. Но если движок работает в deployment-aware режиме, он должен знать, какие джобы его, а какие не его.

И во всех случаях, кроме этого listener-а все работает правильно -- каждый движок выполняет только те процессы, которые у него задеплоены.

Смотрите, у вас на end event hello-world стоит async. Т.е. wait state и новая джоба в бд. Допустим её берет в работу правильный движок, он должен завершить этот элемент и передать управление в родительский процесс, который в другом движке. Как он это должен сделать по вашему?

Т. е. дело в настройках async-before и async-after?

Спасибо за Ваши комментарии. Я завтра на свежую голову подумаю.

Нет. Я например не понимаю как это должно работать между серверами.

Даже call activity. Если не ошибаюсь это синхронная операция. Как она запускает процесс в движке на другом сервере?

> Я например не понимаю как это должно работать между серверами.

По идее очень просто: Движок core-process пишет в базу данных "заявку", что нужно запустить процесс такой-то.

Все остальные движки регулярно проверяют базу данных -- не появились новые заявки на выполнение процесса? (Всякие backoff-timing-и определяют, как часто движок смотрит в базу данных).

Движок domain-hello-world замечает, что во-первых есть заявка на выполнение процесса и во-вторых, этот процесс лежит в domain-hello-world, следовательно его нужно выполнять. Ну и потом этот движок отмечает эту заявку в базе данных, дескать, начали выполнять.

Если у всех движков есть связь с базой данных, и база данных у всех одна, то должно работать.

Я не встречал в исходниках подобного функционала) возможно так глубоко ещё не долез

Это описано в документации и называется гетерогенный кластер.

См. https://docs.camunda.org/manual/latest/user-guide/process-engine/the-job-executor/#cluster-setups .

Здесь еще есть про базу данных, которая используется несколькими движками: https://docs.camunda.org/manual/latest/introduction/architecture/#clustering-model

Ну правильно, там речь идёт о deployment aware job executor.  Т.е. job executor выбирает задачи относящиеся к своим деплойментам. И это логично. Но в вашем случае джоба одного деплоймента передаёт управление в процесс из другого деплоймента

Включите debug для камунды на hello world и по логам будет чётко видно что происходит

На форуме Камунды говорят, что надо поставить async-after ( https://forum.camunda.org/t/why-does-camunda-attempt-to-execute-a-task-listener-in-the-wrong-process-engine/29570/6?u=mentiflectax ). Завтра проверю.

Мне кажется не поможет.  Он все равно будет относиться к деплойменту hello world.

Деплоймент не проблема.

Представьте себе, что у Вас один движок и в нем процесс номер 1.

Вы запускаете приложение, создается деплоймент с первой версией первого процесса.

Потом Вы добавляете второй процесс. Опять запускаете приложение. Создается второй деплоймент с первой версией второго процесса.

Потом меняете первый процесс так, чтобы он вызывал второй. Запускаете приложение. Создается третий деплоймент со второй версией первого процесса.

Если Вы запустите вторую версию первого процесса, то она будет вызывать второй процесс из второго деплоймента и все будет работать.

Нет. Не так. У вас есть цепочка действий. В рамках одной БИЗНЕС-транзакции. От одного wait state до другого. Эта цепочка выполняется в памяти и будет сохранена в бд только когда достигнет wait state. В вашем случае эта цепочка начинается с async before у end event сервера hello world, а заканчивается где-то в родительском процессе на другом сервере.

Продолжение вчерашней истории с listener-ом:

1. Если поставить async-before и async-after на все активности во всех процессах, ошибка все равно происходит.

2. После разговора с нашими экспертами возникло предположение, что это баг в Камунде. Завели тикет в их Джире: https://jira.camunda.com/browse/CAM-13829 .

🙃