Ax2009 SP1 RU6. Пользователи не могут зайти, но уже авторизованные продолжают работать

[rashuf]

Добрый день!
DAX 2009 SP1 RU6, MS SQL 2012 Standard, Windows Server 2012 R2 Standard (и приложение, и база на одном физическом сервере). Все чаще (раньше - раз в пару недель, потом разв в неделю, теперь пару раз в неделю) наблюдается следующая картина - аксапта перестает "пускать" новых пользователей в аксапту, при этом уже авторизованные пользователи продолжают работать. "Не пускает" означает, что при запуске клиента он перестает отвечать - висит окно с заголовком и белым фоном. При наблюдении с помощью process monitor видно, что с клиентской машины уходит 2 пакета, и сервер на них отвечает. В TCP view соединение в статусе established. Порт открыт, база доступна. Служба не "падает". Но дальше этих двух пакетов процесс обмена между клиентом и сервером не идет. Устанавливали обновления ОС, настроен периодический перезапуск служб базы данных и приложений с удалением индексов. В логах ОС ничего, что хотя бы намекнуло на источник. Журнал SQL так же чист. Собирали дампы с помощью process explorer и debug diagnostic tools 2.2, анализировали с помощью скриптов (EMEADAXSupport ) в WinDbg - ничего (при критических падениях ранее эти скрипты помогли исправить ошибки). Нашел вот такую тему на форуме с похожей проблемой, но решения или описания источника в ней не нашел.
В чем может быть проблема? Кто-нибудь наблюдал такое поведение?

[Raven Melancholic]

У нас наблюдалось такое поведение чаще всего тогда, когда кто-то заходил в Аксапту с клиентом, версия которого ниже, чем у сервера.
Если такой пользователь заходил, то через некоторое время переставало пускать других. Может быть у Вас та же беда? Посмотрите значение поля BuildNum в таблице SysUserLog (ну или прямо в интерфейсе в запросах модуля Администрирование) у всех ли оно совпадает.

[Logger]

У нас похожее бывало когда глючил DNS и сервер аоса вываливался из домена.

[Wamr]

Такое случалось, когда кто-то пытался открыть редактор меток, просмотр меток, импорт проекта на рабочем приложении.

[Владимир Максимов]

Наверное, уже проверяли, но все-таки уточню. Ничего подозрительного в методах старта Axapta не делали?

- infolog.startup
- infolog.startupPost
- application.startup
- application.startupPost

При зависании, тем не менее, запись в логе входов пользователя создается?

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

[rashuf]

Raven Melancholic,
действительно, есть несколько пользователей с BuildNum 1000.52 (при этом на сервере 1500.3761). Обновляем - ставим RU6. Но интересно, что раньше, когда приложение стояло на сервере 2008R2, "зависаний" не было. Кстати, в журнале Приложение ОС видно предупреждение с кодом 151 (Object Server 01: Internal aocp revision mismatch. Axapta client from PC310 (0.0.0.0) tried to attach with 5.0.1500.3761 revision of kernel)

Logger,
проверили DNS - вроде все нормально. Не может быть причиной проблемы с DNS на клиентах? Это проверим. Но в журналах контроллера домена никаких упоминаний на этот счет нет.

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

Владимир Максимов,
есть модификация на info.startupPost. Но код корректный. Запись в логах о входе пользователя не создается.

В общем, почти полный букет симптомов
Спасибо за отклик! Будем наблюдать, позже сообщу результаты.

[rashuf]

Добрый день!
Изменение версии клиентов (в 6 случаях - увеличение (поставили RU6), в одном - уменьшение (удалили одно KB)) на зависания не повлияло. Сегодня опять зависла служба.
В описании симптомов забыл упомянуть, что служба AIF, которая работает через BusinessConnector, мгновенно перестает отвечать. Это своего рода мониторинг зависаний
Хочу также поинтересоваться, используется ли такое сочетание ПО (Server 2012 Standard + MS SQL 2012 + DAX 2009 на одном сервере) у кого-нибудь еще? А то есть подозрение, что дело может быть в версии ОС. А пока потихоньку готовим запасной плацдарм в виде виртуальной Windows Server 2012 на Hyper-V. И будем убирать модификацию info.startupPost.

[rashuf]

После нескольких месяцев наблюдений делаем следующие выводы.
Во-первых, после удаления модификации метода info.startupPost() "зависаний" стало гораздо меньше. Несколько раз было, но причины пока неясны.

Во-вторых, были падения службы AOS в момент, когда один из разработчиков пытался открыть редактор меток.

Считаю, что основная причина, отвественная за зависания в 90% случаев, выяснена - модификация info.startupPost().

Всем спасибо за помощь!

[Ivanhoe]

А какой код там был?

[rashuf]

Вот этот метод вызвался в startupPost

boolean closeOpenSession_flx()
{
    int             counter = 0,num;
    int             curSessions,maxSessions;
    int             curSessionId = new xSession().sessionId();
    container       users;
    userId          userId;
    Session         sessionToTerm;
    xSession        session;
    Container       userCon,activeUserCon;
    UserInfo        userInfo;
    ;

    counter = Info::licensedUsersTotal();
    userCon = SysUserInfo::getFullLicense();
    maxSessions = counter - conlen(userCon);
    curSessions = Info::getAllOnlineUser();
    userid = curuserid();
    // Проверка лицензий для приоритетных пользователей
    if (!confind(userCon,curuserid()) && curSessions >= maxSessions )
    {
        sessionToTerm = new Session(curSessionId);
        sessionToTerm.terminate();
        sessionToTerm = NULL;
        box::stop(strfmt("%1! Программа не может быть запущена. Количество активных пользователей превышает количество лицензий. Попробуйте подключиться позже!",
                  xUserInfo::find().name), "Microsoft Dynamics AX Access Control");
        appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
        infolog.shutDown(true);
        return true;
    }
    // Проверка повторного входа того же пользователя
    if (SysUserInfo::checkLicenseAccess(userid))
    {
        for(counter = 1; counter < maxSessions;counter++ )
        {
            session = new xSession(counter, true);
            if(session && session.userId() && session.clientKind()!= ClientType::WorkerThread)
            {
                select firstOnly userInfo
                    where userInfo.id == session.userId();

                if (userInfo && (userid == session.userId()))
                {
                    num++;
                }
            }
        }
    }
    if (num > 1)
    {
        box::stop(strfmt("%1! Программа не может быть запущена дважды!",
                  xUserInfo::find().name), "Microsoft Dynamics AX Access Control");
        appl.globalCache().set(classstr(Info),identifierstr(Autologoff), true);
        infolog.shutDown(true);
        return true;
    }
    return false;
}

if (this.closeOpenSession_flx())
{
    return;
}

[rashuf]

Добрый день!

Ситуация после удаления кода из info.startupPost() улучшилась, но в последнее время стали замечать, что зависания опять учащаются. Есть какие-нибудь предложения/идеи, в чем может быть причина?

У нас же пока только одна идея, как можно исправить - мигрировать на виртуальную машину с Win2008r2.

[Weez]

Комбинация Server 2012 Standard + MS SQL 2012 + DAX 2009 - рабочая, по своему опыту говорю.

[rashuf]

Продолжаем поиск источника "висов".
В процессе обнаружил описание похожего случая. Встречались с таким? Но я так понял, что на AOS описанная проблема не влияла, только клиент на одной конкретной машине.
Пока же сосредоточились на решении конкретной проблемы - зависания при импорте проекта или просмотре меток, о чем писал Wamr. У кого-нибудь встречалось такое же поведение и есть ли решение хотя бы этой проблемы?
Еще поинтересуюсь - проводите ли какие-нибудь процедуры на сервере AOS, кроме резервного копирования? Например, у нас это еженедельный перенос доработок копированием приложения (содержимое папки Appl). Перед этим в приложении-источнике запускается компиляция и удаляются индексы (*.ali,*.aoi,*.alt,*.ahi,*.khi,*.adi). При этом еще встречал совет удалять *.alc файлы. Пока удалили только в тестовой среде.

PS: Еще один симптом - после зависания в первую очередь отваливаются соединения BusinessConnector'а.

[Maximin]

Почистите кэши АОСов, удалите .aoi, .alc. См. соответствующую тему- там готовый батник был.
Сделайте глобальную компиляцию ТОЧНО правильной совместимой версией клиента.
Перезапустите АОС.
Потом наблюдайте. Чудес тут мало бывает. Сертификаты еще истекшие проверить можно и есть ли доступ к crl.microsoft.com - на этапе логина зависания бывают до 2х минут. Клиент действительно совсем висит или просто тупит пару минут, а потом таки логинится?

P.S. А че - в Феликсе уже 2009я?

[rashuf]

Кэш AOSов чистим. Глобальную компиляцию делаем на сервере, версия клиента совпадает с версией ядра.
Клиент действительно зависает - ждали более 10 минут, толку нет - белый экран окна с заголовком Microsoft Dynamics Ax - 1, т.е. не указаны ни наименование приложения, ни обладатель лицензии (как при успешном запуске, при успешном логине).
Для чего нужен доступ к crl.microsoft.com? Но в любом случае доступ есть. Вот ответ

PHP код:

<Error>
<Code>InvalidQueryParameterValue</Code>
<Message>
Value for one of the query parameters specified in the request URI is invalid. RequestId:e2c449d9-c01e-008d-599d-b30bd6000000 Time:2019-01-24T04:28:24.8298493Z
</Message>
<QueryParameterName>comp</QueryParameterName>
<QueryParameterValue/>
<Reason/>
</Error> 


Сертификатов просроченных очень много - и в личных, в промежуточных, и в корневых. В том числе СКБ Контур, ФСС (электронные больничные) и пр. Это может влиять? Ранее никогда не следили за ними. Они автоматически вроде обновляются..

[Maximin]

Цитата:

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

Для чего нужен доступ к crl.microsoft.com?

Позволю себе дать ссылку на свой же тред:
Долгий запуск клиента Dynamics Ax - решение
Там еще много полезных советов.

А далее надо анализировать, что происходит сразу перед зависанием - какой запрос отправляется на SQL, что происходит на локальной машине (запустить Sysinternals Process Monitor или взять Sysinternals Process Explorer свежий).
Попробуйте отключите еще антивирус на сервере (если он там есть, вообще - это зло) и клиенте.

[rashuf]

Здравствуйте!
Локализовали причину "зависания".
Вообще наблюдали 2 типа зависания - во время импорта или просмотра меток и "случайный", без видимой причины.
Причиной в первом случае оказались битые файлы меток для всех языков, кроме русского. Битые, потому что в них были пропущены целые диапазоны меток, например, @RSL14643-@RSL14790, @RSL14799-@RSL15605 и др. Подозреваем, что эти блоки были пропущены во время автогенерации меток. Обнаружили, потому что аксапта зависала во время вызова SysLabel.new() для языка fr-ca. Мы просто удалили файлы всех языков для RSL-меток, кроме русского (*.ald-файлы). Проверили импорт - все нормально, не зависает. Удаленные файлы больше не создались (2 недели прошло). Правда, и новые метки пока не создаем и не импортируем.

Во втором случае блокируется таблица Batch. Выяснили с помощью AxTraceParser'а, стандартного отчета MS SQL Все транзакции/Все блокирующие транзакции и запроса.
AxTraceParser показал, что в сессии AOS последними запросами при логине клиента во время зависания являются выбор записи пользователя из UserInfo, вызов хранимой процедуры CREATEUSERSESSIONS и подсчет количества записей по пользователю в SysClientSessions. При этом при нормальной работе AOS еще "мелькают" запросы обновления Batch, BatchJob для запускаемых пакетных заданий. В зависшей сессии таких запросов нет. Пробовали завершать сессии в MS SQL с помощью kill, закрывать порты (TCP-порты 2719) с помощью CurrPorts. Эти меры не помогают "пробудить" AOS, и потом при подключении клиентов выходит ошибка, что AOS вроде бы недоступен, при этом служба работает.

Я видел, что есть исправление KB 3216955 Continuous dead locks in batch tables. Обсуждалось на форуме. Возможно, портирование этого исправления нам тоже поможет, но я не смог его найти (нет доступа) и не понял из сообщения gl00mie, что и где поменялось.
Коллеги, кто-нибудь занимался адаптацией этого обновления на AX 2009? Что изменилось? Может, с учетом новых наблюдений, вообще в другую сторону надо копать?

PS: запрос

SELECT 
	L.request_session_id               AS SPID, 
	DB_NAME(L.resource_database_id)    AS DatabaseName,
	O.Name                             AS LockedObjectName, 
	P.object_id                        AS LockedObjectId, 
	L.resource_type                    AS LockedResource, 
	L.request_mode                     AS LockType,
	ST.text                            AS SqlStatementText,        
	ES.login_name                      AS LoginName,
	ES.host_name                       AS HostName,
	TST.is_user_transaction            AS IsUserTransaction,
	AT.name                            AS TransactionName,
	CN.auth_scheme                     AS AuthenticationMethod
	FROM sys.dm_tran_locks L
    
	JOIN sys.partitions P
		ON P.hobt_id = L.resource_associated_entity_id
    
	JOIN sys.objects O
		ON O.object_id = P.object_id
    
	JOIN sys.dm_exec_sessions ES
		ON ES.session_id = L.request_session_id
    
	JOIN sys.dm_tran_session_transactions TST
		ON ES.session_id = TST.session_id
    
	JOIN sys.dm_tran_active_transactions AT
		ON TST.transaction_id = AT.transaction_id
    
	JOIN sys.dm_exec_connections CN
		ON CN.session_id = ES.session_id
    
	CROSS APPLY sys.dm_exec_sql_text(CN.most_recent_sql_handle) AS ST
	
	WHERE resource_database_id = db_id()

ORDER BY L.request_session_id

[Logger]

Недавно джобили права. Замножили записи в accessrightslist
Стало тормозить и подписать на логине.
Проверьте такую причину тоже.