ММ
и поэтомук с нагрузкой тоже нет проблем
Size: a a a
2021 May 30
ММ
это работает аналогично у zeebe и камунлы
DG
Ага, но неприятно просто, наверное мои загоны какие-то)))
ММ
при желании можно увеличить long poll
R
Это называется task streaming)) вполне себе техника
R
Вы работали с кафкой?
EI
Да, есть.
В одной из интеграций X5 Group завел ZeeBe как оркестратор. Начинал с 0.20, сейчас 1.0.0 - классно работает
В одной из интеграций X5 Group завел ZeeBe как оркестратор. Начинал с 0.20, сейчас 1.0.0 - классно работает
DG
Нет. Кролик был
DG
Спасибо
DG
Я уже работу сменил и поддерживать то решение больше не надо))) Но если здесь решение будет в пользу камунды, то я только за)))
R
там же вроде в камунде в основе своя очередь. Еще одну очередь поверх другой очереди?
Не понимаю беспричинного стремления к явной event-based архитектуре. Зачем? чтобы тестировать это все хозяйство было в разы труднее?
Не понимаю беспричинного стремления к явной event-based архитектуре. Зачем? чтобы тестировать это все хозяйство было в разы труднее?
SD
А чем не хватало публичного api?
DG
Это что вы имеете ввиду? Там табличка из которой идёт выборка тасок
DG
Честно говоря не помню. Вроде возможности сфетчить конкретную таску.
R
ну очередь можно построить на основе таблички) не обязательно AMQP
A
По zeebe миграции процессов так и не сделали, как менять уже работающие схемы процессов непонятно...
DG
Ну в нашей системе при возникновении таски идёт ее лок и месседж в раббита со всеми данными. Что сделать, чтобы принципиально работало также без шедулед-воркеров?
SD
Скопировать реализацию long polling рестового. Камунда файрит событие о создании экстернал таска, по этому событию выполнется фетч, остальное время тред в паркинге
R
интересно какие вы плюсы пытаетесь достигнуть работая с реббитом вместо воркеров? может нам тоже стоит туда посмотреть еще раз))
SD
У меня есть наброски, но я сейчас далеко от компа