Batch + info() = "RPC error: RPC exception 1702 occurred in session XXX"

[DSPIC]

AX2009 RU5,RU6.
Столкнулись с такой проблемой: если ф-я Info("") вызывается во время отработки пакетного задания, то это однозначно приводит к ошибке вызова клиентского кода в журнале Windows (вид ошибки см. в теме). Сколько раз вызывался метод info(), столько ошибок и вываливается. Замечено также, что часто AOS "захлёбывается" в множестве таких ошибок и падает (есть у нас один пакетник, который за один цикл своей отработки вызывает инфолог около двухсот раз ).
Воспроизвести ошибку довольно просто - берем класс Tutorial_RunbaseBatch в методе run вызываем Info(""), запускаем класс на выполнение в пакетном режиме и наблюдаем за журналом Windows.
Ошибка воспроизводится на совершенно девственных инсталляциях AX2009 RU5,RU6 (другие версии не проверял), а также на OS 2008 Server R2, Win7 (другие версии не проверял).

Естественно, это актуально не только для метода info(), но и для всех схожих методов, таких как error(), warning() - ошибка возникает непосредственно в kernel-методе xInfo.add().
Пока слепил workaround - просто блокируем вызов инфолога для SessionType = Worker, логируя infolog messages в отдельный лог, но хотелось бы обойтись без костылей.

Сталкивался ли кто-то с подобной проблемой?

[Bober]

1) можно попробовать еще костыль (не пробовал, но думаю что сработает): собирать все сообщения одного пакетного задания в textbuffer() и потом выводить в инфолог однократно по завершении задания. По крайней мере, специальный лог вести не придется.
2) off: от чтения всех постов об AX2009 - складывается мнение, что версия в целом крайне кривая и сырая.... такое "оценочное мнение" верное?

[fed]

Я бы начал с проверки кода методов Global.Info() и info.add(). По умолчанию он складывает сообщения в infolog. А стандартный обработчик пакетных заданий эти сообщения из infolog вынимает и складывает в поле batch.info(). Рискну предположить, что у вас в код одного из этих методов добавлены вызовы функций или классов выполняющихся на клиенте. А поскольку клиента как такового у пакетного сервера нету, он обращает ваше внимание на этот прискорбный факт выдачей сообщений о RPC-exception 1702. Кстати у нас весь лог пакетного сервера такими сообщениями забит и он все равно не падает. Так что проверить и почистить методы выдачи сообщений можно, но исходной проблеме это вряд-ли поможет.

to bober: Нормальная система, не сырая. По большому счету уже год как можно пользоваться без особых проблем. Всерьез глючат только Workflow и интеграция с SSRS. Все остальное глючит и падает не чаще чем в третьей версии...

[DSPIC]

Цитата:

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

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

Увы, постороннего кода в этих методах нет; как я упомянул ранее, ошибка возникает непосредственно методе xInfo.add().

Цитата:

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

... ошибка возникает непосредственно в kernel-методе xInfo.add()...

Можно взять стандартную, out of the box AX2009 и смело воспроизвести ошибку.
Вот, к примеру, код метода \Classes\Tutorial_RunbaseBatch\run:

public void run()
{
    #OCCRetryCount
    if (! this.validate())
        throw error("");

    try
    {
        ttsbegin;

        info("Test");

        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;
        }
    }

}

А вот трассировка его выполнения:



В общем, вероятно это баг ядра.
Что касается падения АОС, то пока нет однозначной уверенности в связи с этой ошибкой. По наблюдениям можно сказать:
- внезапнопу падению АОС всегда предшествовала серия этих ошибок в журнале OS (падал как минимум раз в 2 дня)
- после вставки костыля АОС уже неделю не падает (возможно и совпадение, наблюдаем...)

[fed]

Скопировал твой код в метод run класса Tutorial_RunbaseBatch() девстенно чистой 2009SP1RU6. Прогнал три раза. В ивент-логе - тишина. Ни одного сообщения.Может у тебя ядро старое ?

Вообще-то учитывая что большая часть стандартной функциональности время от времени использует info() или warning(), трудно предположить что такую грубую ошибку в ядре не заметили бы во время тестирования, даже в исходной DAX2009 без всяких SP и RollUp. Может это у вас в инфраструктуре какие-то грабли ? Типа какой-нить патч для RPC не стоит (Знать бы какой ) или еще чего-то подобное ?

[Ivanhoe]

Ошибка воспроизводится
Windows Server 2003 R2, Dynamics AX 2009 RU6 5.0.1500.3761.

Такая же тема: http://blogs.msdn.com/b/floditt/arch...batch-job.aspx

[fed]

Цитата:

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

Ошибка воспроизводится
Windows Server 2003 R2, Dynamics AX 2009 RU6 5.0.1500.3761.

ДОбавлю что у меня на рабочей станции w7. А для WS2003 (возможно без R2) ТОЧНО был какой-то патч для RPC, который надо было ставить чтобы 4ка не глючила. Правда, боюсь что точное название патча я потерял...
P.S. Вспомнил. Это было http://support.microsoft.com/?kbid=913184
Только он для WS2003R2 не нужен по моему, да и симптомы там другие.

[DSPIC]

Цитата:

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

Скопировал твой код в метод run класса Tutorial_RunbaseBatch() девстенно чистой 2009SP1RU6. Прогнал три раза...

А запуск в пакетном режиме прогонял?

Хм. Буду эксперементировать. На данный момент тестирую на своём ноуте, WIN7.

Хотя на работе стоит RU6. Попробую обновить у себя до RU6, посмотрим.

[fed]

Цитата:

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

А запуск в пакетном режиме прогонял?

Конечно гонял. Собственно - непакетный режим я и не проверил даже...

[Wamr]

под каким пользователем (какие права) запущен АОС?

[DSPIC]

Цитата:

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

под каким пользователем (какие права) запущен АОС?

Под учеткой, входящей в группу "администраторы".

[Wamr]

Доменные администраторы или локальные?

[DSPIC]

Цитата:

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

Доменные администраторы или локальные?

Локальные.
Ещё добавлю, что все инсталляции AX и OS - x64

[fed]

Цитата:

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

Локальные.
Ещё добавлю, что все инсталляции AX и OS - x64

У меня тоже 64битный AOS под 64битной W7. Пользователь - вообще Network Service.

[DSPIC]

Эээ, кажется победил. Виной всему оказалась эта галка:


Включенная отладка пакетников приводит к генерации ошибки вида "RPC error: RPC exception 1702 occurred in session XXX" при вызове метода info() из пакетных задач.

Пока не могу проверить на боевых серверах, но на моём ноуте работает. Проверено на всех проблемных инсталляциях - лечится.

P.S.Обновление до RU6 эффекта не дало.

[Logger]

Цитата:

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

Скопировал твой код в метод run класса Tutorial_RunbaseBatch() девстенно чистой 2009SP1RU6. Прогнал три раза. В ивент-логе - тишина. Ни одного сообщения.Может у тебя ядро старое ?

У нас тоже такая ошибка лезет.
Ядро 3968 (RU6 + hotfixes)

[fed]

Цитата:

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

Эээ, кажется победил. Виной всему оказалась эта галка:
Вложение 6626

Включенная отладка пакетников приводит к генерации ошибки вида "RPC error: RPC exception 1702 occurred in session XXX" при вызове метода info() из пакетных задач.

Пока не могу проверить на боевых серверах, но на моём ноуте работает. Проверено на всех проблемных инсталляциях - лечится.

P.S.Обновление до RU6 эффекта не дало.

Очень может быть. У меня как раз на ноуте стоит девстенно чистая аксапта с дефолтными установками но без данных и режима отладки. Я в ней только в исходных текстах стандарта копаюсь Соответственно галочка у меня не стоит.

[Logger]

Спасибо за найденные баги - отключил галку - пропали сообщения об ошибках RPC.

[Mykola Galak]

Цитата:

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

Включенная отладка пакетников приводит к генерации ошибки вида "RPC error: RPC exception 1702 occurred in session XXX" при вызове метода info() из пакетных задач

Столкнулся с такой же проблемой. Подозреваю причина RPC exception 1702 кроется в том, что если активирована отладка пакетников, ядро пытается найти дебагер, чтобы переслать туда инфолог. Поскольку дебагер найти не получается, ядро регистрирует ошибку в ивент логе и продолжает выполнять код.

[Logger]

хм.
В виртуалке ax2012 R3 от MS похоже ошибка сохранилась