04.08.2009, 18:58 | #1 |
NavAx
|
Повторения пакетных заданий и уход времени начала
Axapta 4.0
В общем, озаботился неприятной особенностью пакетных заданий, повторяющихся ежедневно или ежемесячно. Дело в том, что если задание по каким-то причинам не начало обрабатываться в заданное время начала, то потом, после выполнения, время начала сместится на фактически получившееся в предыдущей итерации. Это приводит к постепенному "сползанию" времени начала задания, что не всегда хорошо. Чтобы это вылечить, достаточно в классе SysRecurrence отредактировать окончания двух методов: doUnitDate и doUnitWeek перед вызовом this.finish следующим образом: X++: currentTime = startTime; //стало //currentTime = oldTime; было return this.finish(currentDate, currentTime); } Было бы любопытно узнать, чем руководствовались разработчики, когда писали это... Чтобы при нескольких параллельно обрабатывающих одну и ту же пакетную группу пакетных серверах взаимные блокировки не происходили, если задания что-то блокируют? Или чтобы дать пакетному серверу "передохнуть" между заданиями?
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты... |
|
|
За это сообщение автора поблагодарили: Zabr (3). |
10.08.2009, 15:59 | #2 |
Member
|
Цитата:
Сообщение от Maximin
...
когда я нашел причину и полез в методы doUnitYear и doUnitMonth, я обнаружил, что там-то уже и без меня всё хорошо, стоит startTime. ... Цитата:
Сообщение от Maximin
...
Было бы любопытно узнать, чем руководствовались разработчики, когда писали это... ... Была раньше проблема. Суть была в том, что если пакетное задание выполняется раз в минуту, и сервер пару суток не работал, то после запуска сервера он "наверстывал" все упущенное. Т.е., например, быстренько строчил один и тот же отчет 24 * 60 * количество дней простоя. Было неприятно. Вроде решили, что стоит избавиться от этой проблемы. Вроде, избавлялись. Думаю, что причина в этом. Меня сейчас тоже проблема смещения времени старта беспокоит. Сижу думаю.
__________________
С уважением, glibs® |
|
10.08.2009, 16:14 | #3 |
Member
|
Может разработчики хотели, чтобы следующий запуск произошел гарантированно не раньше чем через n * 24 часа для периодичности "n дней". Что-то типа того. Насколько правильно это — вопрос философский.
__________________
С уважением, glibs® |
|
11.08.2009, 11:41 | #4 |
Участник
|
Maximin: 1 - спасибо, 2 - только метод называется не doUnitDate, а doUnitDaу.
|
|
Теги |
batch, пакетная обработка, пакетное задание |
|
Похожие темы | ||||
Тема | Ответов | |||
Дата начала амортизации | 8 | |||
Перепланирование производственных заданий по факту | 11 | |||
Ошибка времени выполнения | 8 | |||
Ошибка времени выполнения | 19 | |||
Учет рабочего времени | 1 |
|