AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.08.2009, 15:44   #1  
Roman is offline
Roman
Участник
 
24 / 10 (1) +
Регистрация: 30.01.2003
Кластер 2 АОСа. Разные приложения.
Коллеги,

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

Проблема:
Загрузили проект. На одном АОСе изменения видны, на втором - нет.
Почему?
Старый 28.08.2009, 22:16   #2  
Андре is offline
Андре
Moderator
Сотрудники компании GMCS
 
2,375 / 464 (20) +++++++
Регистрация: 03.12.2001
AOS то после импорта проекта перезапустили ?
Старый 29.08.2009, 15:04   #3  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,952 / 3230 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Андре Посмотреть сообщение
AOS то после импорта проекта перезапустили ?
Разве это обязательно ?
Старый 29.08.2009, 15:09   #4  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,296 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от Logger Посмотреть сообщение
Разве это обязательно ?
В случае с ДВУМЯ AOS однозначно обязательно.
__________________
Михаил Андреев
https://www.amand.ru
Старый 29.08.2009, 22:03   #5  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Если есть несколько AOS, то обновления нужно проводить централизовано и вдумчиво. Лучший способ, это остановка всех AOS, обновление слоя, удаление и перестройка индексов приложения. Если проект на стадии промышленной эксплуатации (то есть изменения не "пожарные, применяемые при запуске, а плановые и продуманные), то это, на мой взгляд, единственно правильный подход не зависимо от того, один AOS или несколько (заливать на рабочее приложение попроектно может и просто, но за 5 лет работы с Ax часто убеждался, что так делать не следует).
Тем не менее, при запуске часто приходится быстро править некоторые части кода, поэтому нужно быстрый накат изменений и распростаранение этих изменений на всех пользователей без перезапуска AOSов. (если не изменялась структура таблиц).
Для того, чтобы изменения вступили в силу для всех, нужно выполнить некоторые операции, собранные в меню "Сервис \ Средства разработки \ Объекты приложения".
Естественно, что данное меню доступно далеко не для всех пользователей. Поэтому мы (уже далеко не на первом проекте) собрали все эти действия в одном месте и дали всем пользователям права на соответствующий пункт меню.
Естественно, что в промышленной эксплуатации так делать нежелательно, но при запуске вполне допустимо.
Примерно так выглядит код для DAX4 (привожу не полностью класс, а рабочий код, собранный в джоб):
X++:
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; 29.08.2009 в 22:07.
За это сообщение автора поблагодарили: kpoxa (1).
Старый 30.08.2009, 07:43   #6  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Во, дурак старый. Скопипастил код в джоб и решил, что помог людям. А то, что нужно сбросить данные АОС, а джобы работают на клиенте и не подумал. Рабочий код в приложенном проекте.
Вложения
Тип файла: xpo SharedProject_FlushUserData_OVK.xpo (5.3 Кб, 613 просмотров)
За это сообщение автора поблагодарили: fed (5), Poleax (1).
Старый 31.08.2009, 18:17   #7  
greench is offline
greench
Участник
Oracle
 
425 / 74 (3) ++++
Регистрация: 12.07.2007
Адрес: Киев
Есть еще один метод, не требующий остановки АОСов, если переносите объекты, которые уже есть на каком либо слое, но вы в них сделали обновления. Открываете приложение приложение, смотрящее на АОС, в котором по идее должны появиться изменения, становитесь на измененный объект и восстанавливаете его. В любом случае конечно лучше останавливать все дополнительные АОСы, переносить изменения, а потом запускать их, но иногда бывают варианты, что нет возможности сделать перезапуск, да и изменений не много. Кстати, я заметил, что классы передергивать не нужно, изменения в них и так подхватываются.
Старый 31.08.2009, 18:26   #8  
greench is offline
greench
Участник
Oracle
 
425 / 74 (3) ++++
Регистрация: 12.07.2007
Адрес: Киев
Упс, завтыкал, джоб приведенный выше конечно удобнее.
Старый 08.09.2009, 12:31   #9  
Roman is offline
Roman
Участник
 
24 / 10 (1) +
Регистрация: 30.01.2003
Проект грузился, когда работали оба АОСа.
После обнаружения проблемы перезапустили АОСы. Но проблема осталась.
Начали думать, что это из-за Alternative bin directory.

Попробуем класс, предоставленный Raven Melancholic. Результаты сообщу.
Старый 09.09.2009, 14:20   #10  
Maximin is offline
Maximin
NavAx
NavAx Club
 
412 / 346 (12) ++++++
Регистрация: 09.10.2002
Адрес: Москва
Как известный экстремал, поделюсь своими 5ю копейками.
Бывает, что сброс кэшей (из известных 3х пунктов) AOSов не помогает.
Тогда 100% работающий шаманский метод - перекомпилировать на каждом AOSе измененные объекты.
Чем и пользуюсь при необходимости наката на рабочую базу. Т.е. сначала "Восстановить", затем сразу "Компилировать".
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...
За это сообщение автора поблагодарили: Logger (3).
Старый 17.07.2020, 17:55   #11  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,952 / 3230 (115) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Maximin Посмотреть сообщение
Тогда 100% работающий шаманский метод - перекомпилировать на каждом AOSе измененные объекты.
Собственно, мы так и сделали.
Изобрели компиляцию на всех аосах.
Функция последовательно запускает клиента аксапты на каждом аосе и проходит по всем узлам нужного проекта, на каждом узле делает компиляция и восстановление каждого узла дважды (важно именно 2 раза это сделать). Тогда кеш прочищается.

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

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

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

Думаю, может попробовать на каждом аосе импортировать проект xpo с нужными узлами. Возможно это поможет. Или может еще какой способ есть.
Старый 17.07.2020, 20:02   #12  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Ну в 2012 есть какие-то отличия в обработке проектов по сравнению с предыдущими версиями.
Например, у нас была процедура сортировки объектов внутри проекта (кстати, сделанная по мотивам приложения ЦУМ, в котором это появилось тоже откуда-то еще). В DAX4, DAX2009 это работает. А вот в DAX2012 есть особенность - сами элементы сортируются, но в интерфейсе это не отображается (само обновление вызывается, в предыдущих версиях оно срабатывало, а вот в 2012 дополнительно нужно вручную вызывать восстановление).
Не скажу, что тратил время на исследование что теперь делать, но пара попыток исправить ситуацию не помогла, так пока и бросил.
За это сообщение автора поблагодарили: Logger (1).
Теги
aos, cluster, кластер

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Запуск Axapta 3.0 Object Server Manager в качестве консольного приложения gl00mie DAX: Администрирование 2 15.11.2007 11:12
Объединение АОСов в кластер Николай DAX: Администрирование 2 17.01.2007 09:32
перенос приложения kitty DAX: Администрирование 8 04.07.2006 13:08
Разные запросы в 2-х и 3-х уровневой конфигурациях. Что делать?! Anais DAX: Программирование 12 04.11.2004 12:47
Разные дебеты в одном заказе? UNRW DAX: Функционал 15 28.10.2004 14:36

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:31.