вторник, 30 июня 2015 г.

Ошибка при запуске NodeAgent'а: A conflicting IP address and port, хотя все проверено, конфликтов нет

При запуске агента узла (nodeagent) сервера приложений WebSphere Application Server возможна следующая ошибка, приводящая к аварийному останову данного компонента:


Trace: 2015/07/01 10:01:46.318 02 t=8E5E88 c=UNK key=S2 tag= (13007004)
SourceId: com.ibm.ws.hamanager.coordinator.dcs.CoreStackMembershipManager
ExtendedMessage: BBOO0220E: HMGR0031E: A conflicting IP address and port has been detected for the DCS_UNICAST_ADDRESS end point.
czcell\cznoded\nodeagent, czcell\cznodeb\nodeagent members are configured to use the IP address and port combination of IP::PORT.


Далее могут находиться следующие записи:


Trace: 2015/07/01 13:26:56.778 02 t=8E5E88 c=UNK key=S2 tag= (13007004)
SourceId: com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl
ExtendedMessage: BBOO0222I: HMGR0228I: The Coordinator is not an Active Coordinator for core group DefaultCoreGroup. The active coordinator set is

... trace skipped

Trace: 2015/07/01 13:26:56.973 02 t=8E5E88 c=UNK key=S2 tag= (13007004)
SourceId: com.ibm.ws.runtime.WsServerImpl
ExtendedMessage: BBOO0220E: WSVR0009E: Error occurred during startup
com.ibm.ws.exception.RuntimeError: Unable to start the CoordinatorComponentImpl

... trace skipped

Trace: 2015/07/01 10:01:46.524 02 t=8E5E88 c=UNK key=S2 tag= (13007004)
SourceId: com.ibm.wsspi.runtime.component.WsComponentImpl
ExtendedMessage: BBOO0222I: WSVR0401W: Unable to deregister the MBean


В FFDC при этом могут быть следующие записи:


[7/1/15 10:01:46:348 GMT] FFDC Exception:com.ibm.wsspi.hamanager.HAException SourceId:com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl ProbeId:255
Reporter:com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl@b220dd73
com.ibm.wsspi.hamanager.HAException: This process has conflicting ip:port configuration with another member. See previous messages for more info.
at com.ibm.ws.hamanager.coordinator.dcs.CoreStackMembershipManager.(CoreStackMembershipManager.java:147)
at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl.(DCSPluginImpl.java:231)
at com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl.(CoordinatorImpl.java:349)

...

[7/1/15 10:01:46:430 GMT] FFDC Exception:com.ibm.wsspi.hamanager.datastack.DataStackException SourceId:
com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl ProbeId:288 Reporter:com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl@f036c22f
com.ibm.wsspi.hamanager.datastack.DataStackException: Failure creating core stack
at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl.(DCSPluginImpl.java:263)
at com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl.(CoordinatorImpl.java:349)

...

[7/1/15 10:01:46:445 GMT] FFDC Exception:com.ibm.wsspi.hamanager.HAInternalStateException SourceId:
com.ibm.ws.hamanager.runtime.CoordinatorComponentImpl ProbeId:234 Reporter:com.ibm.ws.hamanager.runtime.CoordinatorComponentImpl@331d9876
com.ibm.wsspi.hamanager.HAInternalStateException: failure creating the Coordinator
at com.ibm.ws.hamanager.coordinator.impl.CoordinatorImpl.(CoordinatorImpl.java:356)
at com.ibm.ws.hamanager.coordinator.corestack.CoreStackFactoryImpl.createDefaultCoreStack(CoreStackFactoryImpl.java:88)


Т.е. нам говорят, что невозможно запустить требуемый nodeagent, потому что другой nodeagent имеет пересекающийся по значениям набор портов, однако это - не так!. Т.е. возможно когда-то по ошибке или специально было создано две node с пересекающимся набором портов у соответствующих nodeagent'ов, но эта ситуация давно исправлена, почему же компонент продолжает аварийно завершаться при запуске?

Все дело в файле PROFILEDIR_A/config/cells/CELL/nodes/NODE_B/serverindex.xml. Так как nodeagent аварийно завершает свою работу до запуска синхронизации конфигурации, то у него в данном каталоге остается старый конфигурационный файл serverindex.xml, соответственно компонент продолжает считать, что есть пересечение по значениям ip:port, этакая фантомная боль. Важно обратить внимание, что профиль в данном случае относится к запускаемой node, а в каталоге с профилем нужно найти подкаталог, относящийся к конфликтующей node, там будут два файла: node-metadata.properties и serverindex.xml. Необходимо вручную заменить файл serverindex.xml для соответствующей node, взяв его из профиля с менеджером развертывания (DMGR): .../DeploymentManager/profiles/default/config/cells/CELL/nodes/NODE_B/serverindex.xml.

P.S. Хотел спросить читателей, будет ли им полезна серия заметок по решению вопросов с замечательным сервером приложений IBM WebSphere Application Server? Какие еще компоненты стека нашей корпорации вам были бы интересны: Process Server, Business Process Manager (BPM), Portal, Lombardi или что-нибудь еще? Пожалуйста, ответьте в комментариях. Спасибо.

Понравилось сообщение - подпишитесь на блог

четверг, 25 июня 2015 г.

Ошибка com.ibm.websphere.ssl.SSLException: Cannot get security object from WCCM при запуске WebSphere Application Server

Начну новую серию зарисовок - коротких сообщений, описывающих достаточно стандартные проблемы, с которыми мне пришлось столкнуться, и методы их решения. Может быть буду делиться какими-то лучшими практиками. Начну с проблемы, которая может возникнуть при запуске сервера приложений WebSphere Application Server:


Caused by: com.ibm.websphere.ssl.SSLException: Cannot get security object from WCCM.
at com.ibm.ws.ssl.config.SSLConfigManager.initializeServerSSL(SSLConfigManager.java:212)
at com.ibm.ws.ssl.core.SSLComponentImpl.initialize(SSLComponentImpl.java:145)
... 31 more


Данная проблема возникает из-за того, что файл ...\profiles\PROFILEDIR\config\cells\CELL\security.xml испорчен. Решить проблему можно либо восстановлением данного файла из резервной копии (рекомендуемый вариант), либо копированием его из другого профиля, входящего в данную ячейку: ...\profiles\APPSRV_PROFILEDIR\config\cells\CELL\security.xml.

Понравилось сообщение - подпишитесь на блог

среда, 10 июня 2015 г.

Как может выглядеть JMS 2.1

Интересно, как много коллег, читающих мой блог, помнят, сколько времени жила и безраздельно властвовала спецификация JMS 1.1, предлагающая разработчикам для отправки или приема сообщения написать довольно громоздкий блок кода, больше напоминающий известную притчу о том, что Авраам родил Исаака, Исаак - Иакова, Иаков - Иуду, а потом у них что-то случилось и рожать стали женщины?

Появившаяся в составе Java EE 7 спецификация JMS 2.0 существенно улучшила ситуацию, особенно в части, отвечающей за корректное закрытие ресурсов. Однако нет предела совершенству и сейчас сообщество активно работает над новой версией спецификации - JSR 368 - JMS 2.1. Код подписчика на топик/очередь сообщений, написанный в соответствии с новой спецификацией, может выглядеть следующим образом:



Видно, что развитие спецификации идет по пути упрощения кодирования. Теперь управляемый сообщениями компонент (Message-Driven Bean) не обязан реализовывать интерфейс MessageListener, а метод, в котором реализуется обработка сообщений, не обязан называться onMessage. "Реагировать" на сообщение может любой метод, аннотированный как @JMSListener. Другое интересное новшество - произвольный набор параметров у метода, аннотированного как @JMSListener: разработчик избавлен от необходимости разбирать сообщение внутри данного метода-слушателя вручную (особенное счастье - отсутсвие тягомотины вида TextMessage textMessage = (TextMessage) message;), достаточно лишь объявить произвольный набор формальных параметров метода, аннотировав каждый из них должным образом. Мне лично это напоминает реализацию JAX-WS веб-сервиса: разработчик избавлен от необходимости работать в своем коде с неким SOAPEnvelope и вручную перемещаться по его вложенным элементам с целью найти значения входных параметров. Эту однообразную работу берет на себя среда исполнения, достаточно просто сказать ей какие параметры нас интересуют и как они называются в SOAP-сообщении, используя аннотацию @WebParam. Теперь подобное будет реализовано и в JMS, что лично меня сильно радует, я выступаю за однообразие при решении типовых проблем. В конце-концов парсить сообщения - это не работа для человека, а как говорят в IBM: "Человек должен думать, а компьютер работать".

Исходный код интерфейсов и аннотаций, составляющих спецификацию, доступен на сайте java.net.

Понравилось сообщение - подпишитесь на блог

понедельник, 25 мая 2015 г.

Суровый челябинский программист 2.0

Не знаю, пойдет ли новорожденная дочка по стопам Ады Лавлейс, но достойного человека я из нее воспитать постараюсь. 3680 г., 52 см. счастья.

Понравилось сообщение - подпишитесь на блог

пятница, 22 мая 2015 г.

А вот о работе

Как-то так получилось, что Суровый перестал радовать своих читателей и подписчиков хорошими техническими статьями. За последние несколько месяцев было сделано довольно много, но тема моя настолько специфична - Java и WebSphere Application Server на мейнфреймах IBM (теперь это называется z Systems), что я даже не знаю, будут ли технические статьи по данной теме восстребованы широкой общественностью.

Давайте лучше поговорим немного о другом.

Возможно среди читателей и подписчиков моего блога есть специалисты, эксплуатирующие WebSphere Application Server или другие продукты Middleware от IBM: WebSphere MQ, WebSphere Message Broker, IBM Integration Bus, CICS (!)). Возможно также в вашей компании используются средства мониторинга и автоматизации Tivoli. И все это богатство работает на мейнфрейме, или вы планируете миграцию на мейнфрейм. Наверняка у вас есть вопросы, какие-то замечания, предложения или даже проблемы, связанные с работой наших продуктов. Пожалуйста не стесняйтесь, просто пишите мне на почту psamolysov@ru.ibm.com. Если вы работаете у партнера, разрабатывающего программное обеспечение для мейнфреймов, или задумываетесь о поддержке вашим продуктом этой замечательной платформы, то так же прошу обращаться по любым возникающим вопросам.

Моя роль в IBM называется Client Technical Professional. Это значит, что каждую неделю я должен посещать заказчиков, общаться с их техническими специалистами и помогать решать возникающие вопросы. Помогать вам - это моя непосредственная рабочая обязанность, поэтому даже не думайте стесняться, не зависимо от того, куплена или нет вашей организацией поддержка на тот или иной продукт!

Отдельно отмечу (потому что хотя бы для меня самого это очень важно), в обращении за помощью нет ничего постыдного. Если вы попросили у меня совет или консультацию, то это не значит, что я хоть в чем-то умнее вас или являюсь более квалифицированным специалистом. Вовсе нет! Просто у меня есть бейджик с надписью IBM, который дает право обращаться к действительно умным коллегам внутри компании, включая разработчиков продуктов из зарубежных лабораторий и даже к архитектору IBM JVM (так мне недавно удалось ответить на один интересный вопрос нашего крупнейшего заказчика). Не использовать такие возможности на мой взгляд недальновидно.

Понравилось сообщение - подпишитесь на блог

среда, 11 марта 2015 г.

Как же это я упустил! Java 8 от IBM доступна для скачивания

Не баян, но гармошка!

Скачать под правильную операционную систему можно здесь.


Ну и подтверждение, что это действительно работает:


P.S. Не все знают, как скачать IBM JDK для Microsoft Windows. Для этого необходимо перейти на страницу IBM developer kits и затем проследовать по ссылке IBM Development Package for Eclipse. На открывшейся странице нас интересует последняя группа ссылок: Download the IBM Development Package for Eclipse, Version 6.0, including IBM SDK, Java Technology Edition, Version 8. В результате будет скачан Eclipse SDK и IBM SDK.


Наслаждайтесь!

Понравилось сообщение - подпишитесь на блог

вторник, 3 марта 2015 г.

Правильная платформа для Java EE приложения или как Линукс оказался в 3 раза медленее z/OS

Ваш покорный слуга написал еще одну статью на Хабрахабр - Правильная платформа для Java EE приложений: как z/OS + DB2 оказались в 3 раза быстрее Linux + Oracle.

Краткое резюме: очень быстро мигрировали Java EE приложение, использующее Hibernate, на мейнфрейм и провели сравнительное тестирование, с одной стороны данное приложение на zLinux + Oracle (2 LPAR), с другой - оно же на z/OS + DB2 (1 LPAR). Вариант на z/OS + DB2 работал быстрее в 3 раза. Конфигурация выбрана исходя из требований заказчика, для которого выполняли тестирование, но в принципе соответствует реальным практикам, почему-то именно так и разворачивают - на Linux стараются вынести каждую подсистему на свою виртуальную машину, на z/OS - весь стек разворачивается вместе, тем самым используются примущества операционной системы, в частности Cross-Memory Services - механизм, позволяющий из одного адресного пространства (WebSphere Application Server) обратиться к другому (DB2) с помощью нескольких машинных команд, минуя планировщик ОС. Преимущества подхода перед типичным кодом межпроцессной коммуникации (IPC), содержащем сотни, а то и тысячи машинных инструкций, да к тому же выполняющем обращения к ядру, очевидны любому инженеру, знакомому с операционными системами чуть глубже, нежели на уровне "интерфейс унылый/интерфейс неунылый".

Отдельно отмечу, что исключительно расчетная часть на Java под z/OS выполнялась быстрее на 25%, что является отдельным приветом сторонникам мнения "Java на мейнфрейме тормозит и вообще".

P.S. Очень распространенное заблуждение, что zLinux выполняется только на z/VM. В данном случае и z/OS и zLinux выполнялись на LPAR'ах, VM в тесте не участвовала.

UPD: Хабраэксперты не подкачали, адекватные комментарии и претензии затерялись в ворохе: "Мы веруем в Линуха святого, а вы говорите, что он в чем-то хуже? Вы все врети, вы - сурковскаяпропаганда!!!" Грамотность аудитории оставляет желать лучшего, но это - уже наша недоработка. Основная претензия - разнесение подсистем на линуксе по разным LPAR'ам, но кто виноват, что линуксоиды так деплоят. В целом интерес к теме прослеживается и это не может не радовать.

UPD2: С нетерпением жду реакции анонимных аналитиков с ЛОРа.

Понравилось сообщение - подпишитесь на блог