А для чего вы Definition ID во внешней системе используете?

Ну это надо у наших разработчиков спросить) Видимо для привязки к конкретной версии схемы бп

Без фасада для внешних систем получаются вот такие неудобные ситуации :(

Там что в одну что в несколько, это негативно сказывается на БД. У нас прометеус, и он сам скрейпит метрики, довольно часто. Соответственно и запросов много. Для не сильно нагруженных камунд это может и подойдёт.

Ок. я понял. Спасибо

Если непонятна задача, то сложно что-то советовать
по мне так возможны две ситуации при деплое измененной схемы процесса:
1. Все запущенные экземпляры мигрируют на новую. Новые процессы создаются всегда по последней версии процесса
2. Новые процессы создаются по последней версии. Ранее запущенные дорабатывают как есть.

Как поступать в каждом конкретном случае зависит от масштаба изменений - может быть миграция крайне затруднительна или от бизнесового смысла этих изменений (изменение нормативки к примеру с конкретной даты)

У нас внешняя система знает только Definition Key, который используется для старта процессов
Запущенные процессы имеют businessKey для сопоставления с контекстом внешней системы

На ProcessDefinitionId очень фигово завязываться) у нас бывали ситуации когда ProcessName длиннее 28 символов, что в последствие приводило к тому, что айди не имел в себе имени и версии, а просто был uuid.

@Edwardin4o
А как вы деплоите схемы процессов в кластерах, в которых больше одной ноды? Автодеплой из папки resources? или другой механизм?
Мы сейчас столкнулись с определенными проблемами. Получается ситуация, когда несколько нод одновременно читают из таблицы *_bytearray_*,  пытаются захватить лок на deployment.lock и начинают аффектить друг друга. Активно читают диск, вытесняют кэш и т.д.. В бд начинаются "длинные транзакции", оркестратор рестартит под по таймауту .

У нас используется аннотация из спрингового стартера камунды - EnableProcessApplication. Если она есть, то там не создается дефолтовая деплоймент конфигурация. Вместо нее там будет бин где эта конфигурация через анонимный класс сделана по простому. Благодаря этому как я понимаю у нас все норм работает при деплое, и деплоит схемы только та нода, которая первая залочила через таблицу act_ge_property

Только для этого еще в метаинфе должна быть processes.xml , если не ошибаюсь

Ну собственно у нас так же. Я может чуть не точно описал. По всей видимости все-таки только одна нода берет лок, но потом очень долго читает из bytearray

Еще сам не до конца разобрался в механизме проблемы

Недавно у коллег тоже такое стрельнуло. Долгие транзакциина байтаррэй. Ну в итоге по-моему они решили это на стороне постгри

Вакуум давно не запускался

По-моему для колонки name_ они увеличили в 10 раз сбор статистики

Не, вакуум это уже другая история))) более печальная)

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

Странно. У коллег когда были такие проблемы при деплое, то нашли разницу как раз в том, что у них дефолтовый деплоймент конфиг был в контексте. А у меня в камундах была аннотация эта и в итоге из-за нее был бин  с другим конфигом деплоя(тоже из стартера камунды). Вот в тех где была эта аннотация никогда не было таких проблем с деплоями. Хотя приложухи уже долго живут, и байтаррэй там тоже жирная.

А какая версия камунды?

7.11