Кластер 2 АОСа. Разные приложения.

[Roman]

Коллеги,

Исходные данные:
DAX 4.0 SP1.
2 АОСа на отдельно стоящих серверах объеденены в кластер (галка "Make this AOS instance part...")
АОСы настроены на расшаренную сетевую папку (Application file location).
Alternative bin directory у каждого АОСа своя.

Проблема:
Загрузили проект. На одном АОСе изменения видны, на втором - нет.
Почему?

[Андре]

AOS то после импорта проекта перезапустили ?

[Logger]

Цитата:

Сообщение от Андре

AOS то после импорта проекта перезапустили ?

Разве это обязательно ?

[Михаил Андреев]

Цитата:

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

Разве это обязательно ?

В случае с ДВУМЯ AOS однозначно обязательно.

[Raven Melancholic]

Если есть несколько AOS, то обновления нужно проводить централизовано и вдумчиво. Лучший способ, это остановка всех AOS, обновление слоя, удаление и перестройка индексов приложения. Если проект на стадии промышленной эксплуатации (то есть изменения не "пожарные, применяемые при запуске, а плановые и продуманные), то это, на мой взгляд, единственно правильный подход не зависимо от того, один AOS или несколько (заливать на рабочее приложение попроектно может и просто, но за 5 лет работы с Ax часто убеждался, что так делать не следует).
Тем не менее, при запуске часто приходится быстро править некоторые части кода, поэтому нужно быстрый накат изменений и распростаранение этих изменений на всех пользователей без перезапуска AOSов. (если не изменялась структура таблиц).
Для того, чтобы изменения вступили в силу для всех, нужно выполнить некоторые операции, собранные в меню "Сервис \ Средства разработки \ Объекты приложения".
Естественно, что данное меню доступно далеко не для всех пользователей. Поэтому мы (уже далеко не на первом проекте) собрали все эти действия в одном месте и дали всем пользователям права на соответствующий пункт меню.
Естественно, что в промышленной эксплуатации так делать нежелательно, но при запуске вполне допустимо.
Примерно так выглядит код для DAX4 (привожу не полностью класс, а рабочий код, собранный в джоб):

static void flushCache(Args _args)
{
    ;

    #AOT

    xSession::removeAOC();

//    SysTreeNode::refreshAll();

    TreeNode::findNode(#TablesPath).AOTrefresh();
    TreeNode::findNode(#TableMapsPath).AOTrefresh();
    TreeNode::findNode(#ViewsPath).AOTrefresh();
    TreeNode::findNode(#ExtendedDataTypesPath).AOTrefresh();
    TreeNode::findNode(#BaseEnumsPath).AOTrefresh();
    TreeNode::findNode(#LicenseCodesPath).AOTrefresh();
    TreeNode::findNode(#ConfigurationKeysPath).AOTrefresh();
    TreeNode::findNode(#SecurityKeysPath).AOTrefresh();
    TreeNode::findNode(#TableCollectionsPath).AOTrefresh();
    TreeNode::findNode(#MacrosPath).AOTrefresh();
    TreeNode::findNode(#ClassesPath).AOTrefresh();
    TreeNode::findNode(#QueriesPath).AOTrefresh();
    TreeNode::findNode(#JobsPath).AOTrefresh();
    TreeNode::findNode(#MenusPath).AOTrefresh();
    TreeNode::findNode(#MenuItemsDisplayPath).AOTrefresh();
    TreeNode::findNode(#MenuItemsOutputPath).AOTrefresh();
    TreeNode::findNode(#MenuItemsActionPath).AOTrefresh();
    TreeNode::findNode(#ResourcesPath).AOTrefresh();

    SysFlushDictionary::main(_args);
    SysFlushAOD::main(_args);
    SysFlushData::main(_args);

    xSession::updateAOC();

    xSession::removeAOC();

    SysTreeNode::refreshAll();

    SysFlushDictionary::main(_args);
    SysFlushAOD::main(_args);
    SysFlushData::main(_args);

    xSession::updateAOC();


}

[Raven Melancholic]

Во, дурак старый. Скопипастил код в джоб и решил, что помог людям. А то, что нужно сбросить данные АОС, а джобы работают на клиенте и не подумал. Рабочий код в приложенном проекте.

[greench]

Есть еще один метод, не требующий остановки АОСов, если переносите объекты, которые уже есть на каком либо слое, но вы в них сделали обновления. Открываете приложение приложение, смотрящее на АОС, в котором по идее должны появиться изменения, становитесь на измененный объект и восстанавливаете его. В любом случае конечно лучше останавливать все дополнительные АОСы, переносить изменения, а потом запускать их, но иногда бывают варианты, что нет возможности сделать перезапуск, да и изменений не много. Кстати, я заметил, что классы передергивать не нужно, изменения в них и так подхватываются.

[greench]

Упс, завтыкал, джоб приведенный выше конечно удобнее.

[Roman]

Проект грузился, когда работали оба АОСа.
После обнаружения проблемы перезапустили АОСы. Но проблема осталась.
Начали думать, что это из-за Alternative bin directory.

Попробуем класс, предоставленный Raven Melancholic. Результаты сообщу.

[Maximin]

Как известный экстремал, поделюсь своими 5ю копейками.
Бывает, что сброс кэшей (из известных 3х пунктов) AOSов не помогает.
Тогда 100% работающий шаманский метод - перекомпилировать на каждом AOSе измененные объекты.
Чем и пользуюсь при необходимости наката на рабочую базу. Т.е. сначала "Восстановить", затем сразу "Компилировать".

[Logger]

Цитата:

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

Тогда 100% работающий шаманский метод - перекомпилировать на каждом AOSе измененные объекты.

Собственно, мы так и сделали.
Изобрели компиляцию на всех аосах.
Функция последовательно запускает клиента аксапты на каждом аосе и проходит по всем узлам нужного проекта, на каждом узле делает компиляция и восстановление каждого узла дважды (важно именно 2 раза это сделать). Тогда кеш прочищается.

Это хорошо работало для ax3.0-2009

Но в 2012-й не все хорошо срабатывает.
Периодически бывают проблемы на Security узлах. Для них такой способ не подошел.

Коллеги, как вы сбрасываете кеш по security ветке AOT в 12-ке ?

Думаю, может попробовать на каждом аосе импортировать проект xpo с нужными узлами. Возможно это поможет. Или может еще какой способ есть.

[Raven Melancholic]

Ну в 2012 есть какие-то отличия в обработке проектов по сравнению с предыдущими версиями.
Например, у нас была процедура сортировки объектов внутри проекта (кстати, сделанная по мотивам приложения ЦУМ, в котором это появилось тоже откуда-то еще). В DAX4, DAX2009 это работает. А вот в DAX2012 есть особенность - сами элементы сортируются, но в интерфейсе это не отображается (само обновление вызывается, в предыдущих версиях оно срабатывало, а вот в 2012 дополнительно нужно вручную вызывать восстановление).
Не скажу, что тратил время на исследование что теперь делать, но пара попыток исправить ситуацию не помогла, так пока и бросил.