У меня было два случая, когда происходила такая проблема (симптом: токен не двигался со стартового события).

В первом случае была активность, где делался запрос к базе данных. Соединение было очень медленное, поэтому мы экспериментировали с разными таймаутами. В какой-то момент все перестало работать. Я предполагаю, что как раз из-за таймаутов.

Во втором случае есть deployment ware архитектура, которая развернута на локальной машине разработчика. Все три Камунды подключены к одной оракловой базе. Я предполагаю, что проблема возникает потому, что разработчик дебажит и много времени проходит на точке останова. Вероятно, из-за этого долгого ожидания внутри Камунды сбивается время. Насколько я помню, когда они в таком же режиме работали с H2, то таких проблем не было.

Ну у меня многие процессы запускаются и исполняються синхронно, в виде rest-запросов, поэтому всякие провисания были недопустимы и я много времени потратил на tuning в итоге на production стоит такое

<property name="maxJobsPerAcquisition">50</property>
       <property name="waitTimeInMillis">5</property>
       <property name="maxWait">50</property>
       <property name="lockTimeInMillis">300000</property>
       <property name="backoffTimeInMillis">30</property>
       <property name="maxBackoff">150</property>
     </properties>
   </job-acquisition>
   <properties>
     <property name="queueSize">100</property>
     <property name="maxPoolSize">20</property>
   </properties>

По факту executor спамят каждые 10-20 ms запросы на проверку новых задач

Чёт мне кажется там дело в транзакциях. По идее job executor  должен взять из бд пачку задач, залочить их на себя (установить время лока и свой идентификатор, по аналогии с external task) и положить их в очередь в памяти, откуда их уже будут брать и обрабатывать потоки из пула. Если у вас поток читающий базу не отпускает лок, то что-то тут не то на мой взгляд

так с локами у job executir глобальных проблем особо не бывает. Основная проблема - в настройках по умолчанию job executor после долгого отсутсивя запросов начинат опрашивать пул раз в минуту. То есть двая 15 запросов за 15 минут что видно в статистике по метрикам. Что соверешнно недопустимо в системах максимально быстрой реакции

Если Дмитрий говорит о backoff, то:

Specifies the maximum wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked.
Default Value: 0

Т.е. добычи выбраны, но не могут быть залочены.

И:


Specifies the wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked. This condition indicates that there are other job acquisition threads acquiring jobs in parallel. If this is repeatedly the case, the backoff time is increased exponentially by the factor waitIncreaseFactor. The time is capped by maxBackoff. With every increase in backoff time, the number of jobs acquired increases by waitIncreaseFactor as well.

Т.е. речь о локе параллельным потоком

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

у меня по статистике ща 15 минут идет ну порядка 20000 попыток залочить

и многие неудачны

ну и что... это не проблема

это нормально в паралельной и однвоеменнй работе мноество процессов

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

При этом бэкофф вырастает до бесконечности)))) хотя по идее там должен быть макс предел

ну это да... ну я смотрю на них как на одно целое... для меня главное чтобы процесс исполнялся быстро... а как они соперничают между собой... дело такое :)))

ну я пожтому и поставил

<property name="backoffTimeInMillis">30</property>
       <property name="maxBackoff">150</property>

то есть время вырастет до 150 ms

и все

Для отладки процессов очень не хватает визуализированного выполнения в реальном времени, чтоб, после запуска процесса, можно было наблюдать за прохождением токенов. Этого нет ни в Cockpit, ни в Excamad.