среда, 11 апреля 2012 г.

Ошибка "BEA-149259 Server ... in cluster ... is being brought up in administration state due to failed deployments" и вариант её решения

Ошибка:
В Weblogic-кластере сервер (в моём случае soa_server) стартует в статус ADMIN, а в логе серверы фигурирует ошибка:
...
<Emergency> <Deployer> <BEA-149259> <Server 'soa_server' in cluster 'SOA_Cluster' is being brought up in administration state due to failed deployments.>   
...

Причина:
Особенность состояния ADMIN в Weblogic-сервере: ошибки возникающие в состоянии PREPARE заставляют сервер оставаться в фазе ADMIN.

Вариант решения:
Исправить ошибки в состоянии PREPARE (лучший вариант) или запускать сервер с ключом:
-Dweblogic.deployment.IgnorePrepareStateFailures=true

четверг, 5 апреля 2012 г.

Поиск Java-класса в директории

Для поиска java-класса по всем jar в директории и поддиректориях можно воспользоваться утилитой JarScan (автор Geoff Yaworski). Загрузить её можно с сайта автора или отсюда.

Пример использования:
 $ java -jar jarscan.jar -dir /opt -class weblogic.jdbc.sqlserver.SQLServerDriver
  где /opt - директория для поиска;
       weblogic.jdbc.sqlserver.SQLServerDriver - имя класса.

среда, 4 апреля 2012 г.

Weblogic Cluster: принцип работы Сonsensus leasing

В Weblogic Cluster есть два механизма контроля миграции:
  • Database - информация хранится/изменяется в СУБД;
  • Сonsensus - информация хранится в памяти.
В данной статье пойдёт речь об принципах работы механизма Сonsensus.

Принцип работы:
Допущение: для простоты восприятия принципа работы будем считать, что данные хранятся в виртуальной таблице в памяти мастера (никакого отношения к таблицам СУБД не имеет).

Все сервера кластера периодически отправляют информацию о статусе, так называемые лизы (от слова leasing) мастеру кластера, которую он кладёт в "виртуальную" таблицу в памяти, а от него в ответ получают текущую копию виртуальной таблицы - делается это для обеспечения отказоустойчивость при выходе из строя мастера.
Мастер выбирается всеми запущенными серверами кластера. Сервер становится мастером после одобрения большинства. Если Node Manager сообщает, что статус сервера:
  • остановлен (SHUTDOWN), то потенциальный мастер считает, что остановленный сервер одобрил его кандидатуру, как мастера;
  • неизвестен (UNKNOWN), то потенциальный мастер считает, что сервер не одобрил его кандидатуру;
  • запускается (STARTING), то состоится перевыбор мастера (так же это случится при выходе из строя самого мастера), где основной критерий выбора - наименьшее время старта сервера.
Механизм Сonsensus требует большинства серверов для продолжения функционирования: при выходе из строя (или невозможности доступа к мастеру) сервера кластер логически делится на две части - большая часть кластера продолжает, а меньшая завершает функционировать (переходит в статус FAILED).

В двухмашинной конфигурации использование Сonsensus Leasing проблематично и рекомендуется использование Database Leasing.

Пример:
При старте первого сервера он ищет остальных участников кластера, чтобы узнать есть ли мастер:
Если нет мастера, то он становится мастером:

При старте второго сервера из кластера он ищет участников кластера, находит первый сервер, являющийся мастером:
Далее оба сервера пересматривают вопрос по мастеру кластера: если время старта второго меньше, чем первого (который на данный момент является мастером), то мастером становится второй сервер:
Аналогично с третьим и последующим серверами.