DK
да, можно глобально
Size: a a a
2021 September 22
DK
просто у нас некоторые делегаты вызывают сторонние системы, а они не очень шустро отвечают, и иногда вызовы зависают более чем на 5 мин. А камунда грохает процесс (начинает ретраить его)
SD
Чёт я не встречал такого поведения, хотя долгие выполнения были
SD
Лок может слетать и повторный запуск, но чтобы прям тред рубился...
DK
я заметил такое при зависании делегата на 5 мин
OM
А зачем использовать делегаты для вызова внешних сеовисов? Есть же external tasks
DK
Это как пример
SD
Хех... не всегда есть возможность править внешний сервис
EZ
Да там есть ограничения на лок джоба. LockTimeInMillis за это отвечает по-моему
EZ
Но если вы не укладываетесь в 5 минут, то это очень плохо для вашего приложения.
SD
Можно проверить легко. Сделайте делегат со sleep и обмажьте логами. Все сразу наружу вылезет
DK
так и сделал
SD
И что? Тред убивается? InterruptedException (или как он там...)?
OM
Так его не нужно править, его нужно просто вызвать и когда он ответит, продолжить выполнение процесса
DK
Самое интересное что такого лога не было. Это по той ошибке, что я пару дней назад писал. Когда у меня терминировался процесс, но при этом когда он из слипа выходил - продолжал бежать, а потом чухал, что процесс уже ушел по фейловой ветке и завершен
SD
Эм... это как?
SD
Ну так тут дело в локе, а не в том что камунда делегат убивает
SD
Делегат не убирается, он продолжает жить, джоба повторно берётся в работу
OM
Пишем хендлер внешней задачи, который пинает внешний сервис, а когда он отвечает (он же как-то уведомляет ваш сервис) при обработке завершаем внешнюю задачу Camunda и процесс продолжается
SD
Ну можно и так, да