та никто не обижался и помощи не просил, вам не нужно решать мои проблемы, я просто уточнил момент по работе с внешними задачами, после того как проштудировал и отдебажил код камунды, чтоб понять для себя, что я ничего не упустил

если не секрет - какие то реальные плюсы есть, по сравнению с rest?
или java-api это тоже самое что и в ресте, и по факту тот же самый поллинг?

я из мира .net-а, поэтому для нас пока только rest интерфейс доступен, но думаю может java прослойка упростит жизнь? в паре с какой нибудь кафкой

ну я отказался от кафки или mq когда просто осознал что camunda topic по сути это тот же самый топик mq системы. Просто реализованный чуть по другому. И на которую через worker подписываешся

ну вообще честно говоря я этим и руководствовался тоже. Особенно с учетом того что с кафкой тоже по такой же модели пришлось работать (poll)

тоже самое, только вместо пуллинга по HTTP идет пуллинг БД

ну это уже недра движка, да там цикличный опрос БД вроде я видел

p.s. поллинг, пуллинг это немного другое)

расшифруйте, что это?)

ну poll это опрос, а pool это бассик))

По взаимодействию с БД вариантов не много. В любом случае таску нужно лочить и комплитить во worker id. В целом нужно смотреть по желаемым сценариям.  При низкой скорости генерации тасков и допустимом высоком latency можно по таймеру раз в минуту, например, лезть в БД и все выбирать.  Сам рест апи, как я уже писал, реализует лонг поллинг, и там не тупой циклический опрос. Грубо говоря, если тасков не хватает на пачку, то поток уводится в park. В engine при создании external task дергается метод fire, который пробуждает тред и он опять идет в БД. Сами хттп запросы при этом стоят в очереди. При это в мультиинстанстной системе к этому сценарию есть вопросы.
Но если нужно пушить в кафку, то это работает норм. Есть поток, который подписывается на событие создания таска, при создании таска он пробуждается, лезет в БД, и пушит зафетченное в кафку. При высокой "плотности" он за раз будет вытягивать больше. И тут нужно именно по профилю нагрузки смотреть какой метод предпочтительнее, чтобы наиболее оптимальное кол-во запросов было.

ну все же понимают о чем речь)

ну да, я просто ворчу уж, просто есть еще pooling - объединение в пул))

При поллинге хттп, точно также идет поллинг БД ) Речь просто о другом транспорте. И тут речь опять о сценариях. Моя позиция: без крайней необходимости архитектуру не усложнять, пока взаимодействие по ресту решает все проблемы и справляется с нагрузкой, нет смысла уходить на другие варианты.
Есть сценарий когда через эксетрнал таски решают проблему долгих вызовов сторонних систем (чтобы не лочить на долго тред таск экзекьютора. Тогда тут вообще транспорт никакой не нужен. В соседнем потоке фетчатся таски и отдельным пулом тредов обрабатываются.

Самое интересное начинается когда для разных топиков хотят использовать разные транспорты и сценарии))))

да, я уже столкнулся когда один "долгий" топик, съедал все свободные worker-потоки, т.к. исполнение задачи в синхронном режиме

переводить в асинхронный режим тоже может стать проблемой - можно "уронить" другую систему пиковой нагрузкой

Ну так она сама должна управлять этим. Размер пачки и т.д.

к сожалению не все системы имеют такой функционал

Не совсем понятно. Вы же сами должны реализовать клиентский код для external task