BiTel

Добрый день.
Недавно столкнулся с ситуацией, когда одна задача в планировщике повисла, затем через полчаса запустилась её копия и тоже повисла, и так далее, пока не кончился scheduler.periodic.thread.count.
После этого вообще все задачи перестали запускаться.
Вот я и думаю - а зачем вообще планировщик пытается запустить второй раз задачу, которая у него ещё с прошлого раза не отработала? Может быть есть смысл ограничить это? Хотя бы опциональным флагом в конфиге.
Вообще когда может потребоваться такая логика, что 2 одинаковые задачи могут работать одновременно? По-моему, для пересчётов и т.п., наоборот, нельзя запускать одновременно.

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

Можно конечно написать свой класс SingleExecGlobalScriptBase extends GlobalScriptBase, куда добавить менеджмент блокировок и проверку наличия блокировки перед выполнением (по имени класса, например). Но не хочется изобретать велосипед. Мне кажется, это должно быть в самом шедулере.

Там есть уже такая возможность, и ограничение параллельного запуска и просто схлопывание одинаковых задач если они сейчас в очереди.
См. например в синхронизаторе церберкрипта итд.
Просто не везде реализовано, не во всех тасках.

Одновременно вообще без разницы, можно все по очереди запускать, просто это неэффективно же. Зачем мариновать в очереди если можно рядом запустить.
Но потеряться они не должны, даже если с виду одинаковые. Например, запустилась синхронизация по двум картам после редактирования их оператором.
Но эта система учитывает это, для каких случаев одинаковые а для каких нет.

_________________
I'm clever. I've got a computer.

ru.bitel.bgbilling.modules.cerbercrypt.server.task.Synchronizer ?

Не нашёл по коду в 7.1 ничего похожего там.

код конечно в ядре, а там только задаются айдишники

_________________
I'm clever. I've got a computer.

я наврал, это в RunTask, а не самих тасках

_________________
I'm clever. I've got a computer.

Ага, глянул: по getUniqueKeyQueue несколько одинаковых задач схлапываются в очереди в одну перед запуском, а по getUniqueKeyParallel будут по-очереди выполняться.

А для TaskBase не думали такую же логику сделать?
Например, можно из конфига таски брать режим параллельного выполнения: 0 - всегда, 1 - в очередь, 2 - не выполнять, 3 - не выполнять и слать аларм "задача всё ещё работает". Для глобальных скриптов тогда пользователь сам сможет прописать, а стандартные задачи планровщика задать жестко. Например, помню, что были проблемы в Dialup, если 2 раза ткнуть пересчёт сессий параллельно - трафики двоились.

Ну в смысле те что по расписанию вроде бы нелогично так ограничивать...
То есть по идее это ошибка должна быть.
А этот механизм действует на всякие так или иначе добавляемые через действия оператора - запуски перерасчётов, обновления карт итд.
Хотя я уже точно не помню почему сразу для TaskBase не получилось это сделать, надо подумать, но всяко туда бы сделали если получилось.

_________________
I'm clever. I've got a computer.

Сделал кароч.

Базовый скрипт:

Пример использования:

а если запустятся два калькулятора разных экземпляров модуля?

а... или я не понял - это для какого случая глоб скрипт, ручного запуска?

_________________
I'm clever. I've got a computer.

Ну это именно для глобальных скриптов, а им, как мы знаем, параметры нельзя передать из конфига задачи планировщика
Поэтому не получится использовать один и тот же класс глобального скрипта в двух задачах планировщика с разными настройками (mid например). Поэтому пишутся разные классы.

Но вообще можно заморочиться и локи объединить по группам. Чтобы несколько разных скриптов могли лочить друг друга. Через аннотации, например, передавать их. Заодно изучу, как свои аннотации пилить Но на практике это редко нужно.
Можно ещё разные типы локов сделать: выдавать ошибку, ждать (с таймаутом/без), молча завершаться.

да диспач в пример, я правда не знаю поправили это или нет, когда он вешал весь планировщик

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

это про что речь?

_________________
I'm clever. I've got a computer.