DAX 2009. Как отлаживать BatchJob?

[konfet]

Ситуация такая. Имеем некое периодическое задание (потомок RunBaseBatch), суть которого - в периодической рассылке email-ов клиентам.
BatchJob работает в принципе нормально, но примерно раз в три дня намертво виснет. После того, как его вручную прибить и снова запустить - отрабатывает как ни в чем не бывало...
Поставлена задача - найти и устранить причину зависонов.
Объем кода периодического задания довольно значителен, поэтому "метод научного тыка" представляется крайне контрпродуктивным... кроме того, причина в принципе может крыться не в кривом коде, а в конфигурации bacth сервера, правах доступа и тп.
Разумеется, можно создать таблицу логов и всюду в подозрительных местах расставить выброс в этот лог строк со стеком, значениями переменных и т..д. Однако, что-то мне подсказывает, что такого результата можно добиться и без утомительной мышиной возни...
Вопрос к гуру: есть ли, например, возможность окружить метод run() соответствующего класса скобками типа

PHP код:

try
{
  run();
}
catch(Exception::<что-то>)
{
  //  если время выполнения джоба больше заданного значения, то 
  //  заканчивать/перезапускать/выполнять другие действия 
  //  типа записи обстоятельств зависона в лог. В идеале - выплевывать 
  // в инфолог информацию, на какой именно строке кода зависон произошел.  
} 


или же, может быть, есть и другой рациональный подход к решению такой задачи? Профайлер?

[Logger]

Сделать то можно.
Можно по логу выполнения пакетов (History таблички) постфактум анализировать что долго выполнялось.
Бывают блокировки на batch табличках которые мешают вовремя стартовать пакетам. Следите за ними.

[konfet]

Цитата:

Сообщение от Logger

Сделать то можно.
Можно по логу выполнения пакетов (History таблички) постфактум анализировать что долго выполнялось.

Это вы про кнопочку log на форме Batch Job History? Увы, создатели job-a не озаботились вообще никаким инфологом... переписывать надо будет.

Цитата:

Бывают блокировки на batch табличках которые мешают вовремя стартовать пакетам. Следите за ними.

А что это за таблички и блокировки и как с ними бороться? на SQL сервере с помощью sp_locks()? Киньте, пожалуйста ссылкой, где про это почитать.

[Logger]

Цитата:

Сообщение от konfet

Это вы про кнопочку log на форме Batch Job History? Увы, создатели job-a не озаботились вообще никаким инфологом... переписывать надо будет.

В это табличке есть время старта и время завершения пакета. - можно тупо выгрузить в Excel и посчитать разницу и найти большие значения.

[arhat]

если отправляете через sysEmailBatch можно попросить администраторов проверить на ошибку sysEmailBatch.parmEmailAddr() адресс рассылки. У меня clr error периодически вонзникал. try() catch(retry) помог. Причину так и не нашел. В ax 12 хорошо можно отладить)))

[fed]

Правильнее в таких ситуациях использовать Trace Parser и трассировку сервера. Этот механизм как раз и предназначен чтобы снаружи можно было посмотреть в каких именно методах крутится зависшая (или просто задумывшаяся) сессия. Есть, конечно, шансы что вы вообще трассы не обнаружите, но это будет говорить что либо у вас там запрос на сиквеле висит в блокировке или исполняется 4ые сутки из за кривого плана запроса; либо у вас какой-то тяжелый системный глюк, из за которого реально ядро аксаптовские виснет.

Другой вариант - собрать dump ax32serv.exe в тот момент когда батч висит и проанализировать этот дамп с целью найти функцию и номер строки в которой данная сессия висит.

[dech]

Цитата:

Сообщение от konfet

Вопрос к гуру: есть ли, например, возможность окружить метод run() соответствующего класса скобками типа

PHP код:

try
{
  run();
}
catch(Exception::<что-то>)
{
  //  если время выполнения джоба больше заданного значения, то 
  //  заканчивать/перезапускать/выполнять другие действия 
  //  типа записи обстоятельств зависона в лог. В идеале - выплевывать 
  // в инфолог информацию, на какой именно строке кода зависон произошел.  
} 


или же, может быть, есть и другой рациональный подход к решению такой задачи? Профайлер?

Попробуйте использовать подобную конструкцию. Желательно, чтобы вы не пихали метод run() внутрь защищенной секции, а саму секцию делали внутри конкретного метода, где находится CRUD-операция. На выбросе исключения можете вывести конкретное сообщение в инфолог.

    #OCCRetryCount
    ;

    try
    {
        ttsbegin;

        // ...
        
        ttscommit;
    }
    catch (Exception::Deadlock)
    {
        retry;
    }
    catch (Exception::UpdateConflict)
    {
        if (appl.ttsLevel() == 0)
        {
            if (xSession::currentRetryCount() >= #RetryNum)
            {
                throw Exception::UpdateConflictNotRecovered;
            }
            else
            {
                retry;
            }
        }
        else
        {
            throw Exception::UpdateConflict;
        }
    }

[konfet]

Цитата:

Сообщение от fed

Правильнее в таких ситуациях использовать Trace Parser и трассировку сервера. Этот механизм как раз и предназначен чтобы снаружи можно было посмотреть в каких именно методах крутится зависшая (или просто задумывшаяся) сессия.

Спасибо, будем пробовать...

Цитата:

Попробуйте использовать подобную конструкцию. Желательно, чтобы вы не пихали метод run() внутрь защищенной секции, а саму секцию делали внутри конкретного метода, где находится CRUD-операция.

Это, наверное, не мой случай, так как рассылка мейлов, очевидно не связана с блокировками SQL. И если там есть и какие-нибудь апдейты, то 99% не они являются причиной зависона. Но все равно спасибо.
ЗЫ
Или же вы имеете ввиду, что catch отработает при любом зависоне, даже если он не вызван SQL операцией? Тогда странно...