EZ
И норм работает?
Size: a a a
2020 October 21
EZ
При таких же переменных
АП
Чуть позже тестить буду, отпишусь)
2020 October 22
AK
Распределённая база данных, как интересно! А какие ещё есть распределённые БД, на которых камунду можно запустить?
DK
нету больше)
DL
вообще набор баз очень ограничен, sqllite к примеру, не поддерживает
AK
Правильно ли я понимаю, что мы делаем один кластер с нодами , например, в америке, европе, азии, запускаем там эту базу, камунду и запросы пользователей у нас летят в те инстансы, которые территориально ближе к тому, кто запрашивает, но с точки зрения наших приложений это работает как будто всё в одном месте?
DK
Правильно ли я понимаю, что мы делаем один кластер с нодами , например, в америке, европе, азии, запускаем там эту базу, камунду и запросы пользователей у нас летят в те инстансы, которые территориально ближе к тому, кто запрашивает, но с точки зрения наших приложений это работает как будто всё в одном месте?
что-то типа
АП
И норм работает?
Да, все заработало :)
SD
Да, все заработало :)
я вот такой комментарий нашел )
https://forum.camunda.org/t/vs-usage-in-expressions/10694
https://forum.camunda.org/t/vs-usage-in-expressions/10694
АП
Да, тоже на него вчера натыкался, но хотел послушать, как на деле работает. Потому что локально и так и так работало, но после погрузки на сервак # перестало работать. По результату буду всегда использовать $)
GG
Добрый день! Я тут сейчас пытаюсь тюнить камунду по производительности - у меня банальный external service task может до 20 секунд болтаться в очереди до того, как его схватит executor. Куда копать?
Если кому-то интересно, проблема решилась путем написания собственной реализации BackoffStrategy и передачи её билдеру ExternalTaskClient.
DK
Если кому-то интересно, проблема решилась путем написания собственной реализации BackoffStrategy и передачи её билдеру ExternalTaskClient.
ссылку на гит скорее
GG
GG
Вот этот интерфейс надо наследовать
GG
Реализация по умолчанию, если список выхваченных задач пустой, начинает увеличивать время между последующими запросами от 500мс до минуты.
SD
Реализация по умолчанию, если список выхваченных задач пустой, начинает увеличивать время между последующими запросами от 500мс до минуты.
Вы только не забудьте, что этот бэкофф придумали не просто так, и это компромис между "временем подхвата" и частотой "дерганья сервиса". Выбирайте параметры осознанно ))))
GG
Безусловно :) но дефолтный рост времени по экспоненте до минуты - это тоже перебор. Я алгоритм поменял на линейное увеличение до 10с, если задач нет, и плавное уменьшение вплоть до 250мс, если задач больше чем одна
YY
Всем привет, а кто-нибудь уже мигрировал на 7.14?
Я вот сейчас пытаюсь и получаю ошибку парсинга схемы:
————
org.camunda.bpm.engine.ParseException: ENGINE-09005 Could not parse BPMN process. Errors:
* One of the attributes 'class', 'delegateExpression', 'type', or 'expression' is mandatory on serviceTask.
————
Тип таски - коннкетор. Сравнил исходники с предыдущей версией, вроде бы всё одинаково. Раньше не ругался, а теперь стал.
Читал, что они перетащили connect в зависимости обязательные, может как-то с этим связано? Есть идеи?
Я вот сейчас пытаюсь и получаю ошибку парсинга схемы:
————
org.camunda.bpm.engine.ParseException: ENGINE-09005 Could not parse BPMN process. Errors:
* One of the attributes 'class', 'delegateExpression', 'type', or 'expression' is mandatory on serviceTask.
————
Тип таски - коннкетор. Сравнил исходники с предыдущей версией, вроде бы всё одинаково. Раньше не ругался, а теперь стал.
Читал, что они перетащили connect в зависимости обязательные, может как-то с этим связано? Есть идеи?
R
судя по сообщению в сервис таске просто не заполнен параметр Экспрешн