DK
Джоба закрывается один раз - job execturs на нодах читают джобы и раздают треды в ноде под их выполнение, тред при выполнении джоба пытается оптимистично его закомитить
Size: a a a
2019 May 31
DK
Иногда бывает, что нода одна пыталась сделать джоб, который уже сделали
DK
Но это редко
DK
Джоб != Квадратик в процессе если что
DK
Квадратик в процессе это activity
AK
Джоб будет примерно квадратик, только если галочки Asynchronous Continuations ваши лучшие друзья =)
OS
"When a process is deployed, the process engine creates a Job Definition for each activity in the process which will create jobs at runtime."
OS
ну не суть. таймер допустим не такая интересная история, его можно с какой-до дискретностью запускать чтобы проверять пора или не пора. Интереснее в варианте мы ждем события из очереди.
DK
Учёные не такие дураки как вы думаете, Олег :)
OS
не знаю к чему эта реплика. Лично я просто пытаюсь понять как это работает, чтобы понять чего можно ждать.
OS
вопросы на мой взгляд очень важные с точки зрения эксплуатации
DK
Это из одного несуществующего сайта, почему-то думал что вы про него знаете. А в целом я про то что тут все идиоматически, максимально ожидаемым способом
DK
Никакой магии и неожиданностей или странных решений
OS
старею, на юмор становлюсь туговат). Но считаю что главное чтобы "Иногда бывает, что нода одна пыталась сделать джоб, который уже сделали"
не случилась в танзакционном бизнесе по отношению к платежке на 100 мультов.
не случилась в танзакционном бизнесе по отношению к платежке на 100 мультов.
DK
События из очереди мы сами читаем, потом через java api специальным методом коррелируем его. Это коммитит джоб в базу и процесс сдергивается куда надо
DK
старею, на юмор становлюсь туговат). Но считаю что главное чтобы "Иногда бывает, что нода одна пыталась сделать джоб, который уже сделали"
не случилась в танзакционном бизнесе по отношению к платежке на 100 мультов.
не случилась в танзакционном бизнесе по отношению к платежке на 100 мультов.
Так это не значит что такая ошибка что-то там ломает, это оптимистик лок
DK
Задача была уже выполнена
DK
События из очереди мы сами читаем, потом через java api специальным методом коррелируем его. Это коммитит джоб в базу и процесс сдергивается куда надо
Если в этот момент нас убили, то, судя по всему, то обычная история с перечитыванием сообщения или как это там лечится
DK
это всё правильные вопросы, согласен. надо тест провести какой-нибудь и статью написать. Давайте об условиях подумает. 1 кейс я понял: делаем 4 ноды, вырубаем 3 и смотрим чо происходит. Внутри процесс какой-нибудь интеграционный с парой таймеров