вторник, 25 августа 2015 г.

I used to ...


Просто не мог не оставить это здесь:


Моему самому любимому Hello World'у позавчера исполнилось три месяца и мы продолжаем расти.

З.Ы. Для изучающих английский комикс отлично помогает отработать использование выражения used to.

З.З.Ы Ссылка на оригинал.

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

четверг, 13 августа 2015 г.

Об увеличении производительности работы Java 8 на мейнфрейме IBM z13

Корпорация IBM вкладывеет воистину огромные усилия в развитие платформы Java. По сути данная платформа является одним из самых важных стратегических направлений для компании. Ключевое достоинство Java-приложений - это возможность немедленно отреагировать на увеличение производительности работы аппаратного обеспечения, используя Just-In-Time (JIT) компилятор, встроенный в последние релизы Java SDK. Ранее Суровый уже рассказывал о преимуществах, которые предоставляют мейнфреймы IBM и операционная система z/OS для работы ваших Java-приложений (в частности, мы уже видели, что связка z/OS + DB2 может работать в 3 раза быстрее связки Linux + Oracle), теперь же хочу поделиться относительно свежими данными.

Новые горизонты в росте производительности работы приложений открываются при совместном использовании возможностей IBM Java 8 и z13, таких как встроенный в новые процессоры SIMD - Single Instruction Multiple Data векторный движок, выполнение вычислений в несколько потоков на одном ядре (SMT) и улучшенная функция поддерки криптографии (CPACF - CP Assist for Cryptographic Function). Использование всех данных возможностей обеспечивает двукратный рост производительности на ядро (throughput-per-core) для приложений, активно использующих криптографию, и рост до 50% для остальных приложений.

Защищенный сервер приложений

На диаграмме приведены экспериментально полученные данные, демонстрирующие более чем двукратный рост производительности приложений, доступ к которым защищен с помощью SSL. В качестве платформы использовался сервер с 1-м CP и 4 zIIP. За базу взята производительность приложений при использовании IBM Java 7 SR4 на мейнфрейме zEC12.


Разница в производительности между Java 7 и Java 8 объясняется тем, что последние версии JVM используют SIMD и другие инструкции процессора z13. Крайний правый столбик отображает увеличение производительности, вызванное включением SMT на специализированных процессорах zIIP.

Java Store Inventory и Point-of-Sale

Приложение Java Store Inventory and Point of Sale Application представляет собой stand-alone программу, основанную на IT-инфраструктуре реально существующей ритейлинговой компании. Бенчмарк объединяет точку продаж, обработку онлайн-платежей и дата-майнинг. В коде используется множество возможностей языка, а так же функции компрессии и криптографии.


Диаграмма показывает увеличение производительности, достигаемое за счет использования платформой IBM Java 8 криптографических функций (CPACF), SIMD и SMT для zIIP на мейнфрейме z13. Наглядно виден рост производительности на 36% при использовании Java 8 по сравнению с Java 7 SR4 на мейнфрейме zEC12 и дополнительные 30% прироста производительности при работе Java 8 на z13 со включенным SMT.

Обработка бизнес-правил

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


Использование Java 8 для обработки бизнес-правил задействует преимущества векторных инструкций SIMD и SMT для zIIP на мейнфрейме z13, что позволяет достигнуть существенного прироста производительности в расчете на одно ядро процессора. На диаграмме видно, что использование Java 8 на мейнфрейме z13 без SMT дает прирост производительности на 66% по сравнению с использованием Java 7 SR4 на мейнфрейме zEC12. Дополнительные 37% прироста производительности достигаются за счет включения SMT на специализированных процессорах zIIP.

четверг, 6 августа 2015 г.

Живьем брать демона!

Вот бывает так в жизни, что ты сидишь никого не трогаешь, починяешь примус, переносишь менеджер развертывания DMGR сервера приложений WebSphere Application Server for z/OS на другой LPAR, а он там не работает. Т.е. никак. При этом адресные пространства живые, а соответствующие порты никто не слушает. И в логах ничего. Но, как доказали наши предки ровно 100 лет назад, русские не сдаются, поэтому проблему можно и нужно решить.

Если посмотреть содержимое файла /wasv85config/CELL/DMGR/DeploymentManager/profiles/default/config/cells/CELL/nodes/DMGR/servers/dmgr/was.env, то там можно увидеть строчки, ссылающиеся на не верный LPAR, т.е. на тот, с которого мы перенесли менеджер развертывания:


daemonInstanceName=LPAR1
server_configured_system_name=LPAR1
daemon_start_command_args=JOBNAME=DMNC,ENV=CELL.ZPLEX.LPAR1,REUSASID=YES
daemon_was_env_file=/wasv85config/CELL/DMGR/Daemon/config/CELL/ZPLEX/LPAR1/was.env


Недостаточно просто исправить значения данных параметров в файле was.env! Важно помнить, что данный файл генерируется менеджером развертывания и рано или поздно внесенные вручную изменения будут отменены. Изменять необходимо переменные окружения сервера приложений и файл server.xml.

Переменные окружения можно отредактировать с помощью консоли администрирования сервера приложений: Environment -> WebSphere variables, чтобы проще было найти нужные переменные необходимо выбрать Scope - Node=dmgr.


Файл server.xml расположен в каталоге /wasv85config/CELL/DMGR/DeploymentManager/profiles/default/config/cells/CELL/nodes/DMGR/servers/dmgr. В данном файле необходимо найти строчку

<properties xmi:id="Property_15" name="was.ConfiguredSystemName" value="LPAR1" required="false"/>

и изменить значение атрибута value на актуальное.

P.S. За подготовку материалов к заметке благодарю Александра Анискина, ведущего программиста ГВЦ ОАО "РЖД".

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

понедельник, 27 июля 2015 г.

Почему мой DMGR не видит экс-стэндалон узел, успешно подключенный с помощью addNode?

Давеча Суровый выполнял эксперимент по подключению готового стендалон-узла сервера приложений IBM WebSphere Application Server v8.5.5 for z/OS к ячейке. В процессе обнаружилось, что, не смотря на успешное завершение работы JOBBBOWADDN, вызывающего команду addNode, менеджер развертывания (DMGR) "не видит" свежеподключенный узел.


Сам узел (CZNODEB) при этом запущен и соответствующее адресное пространство существует в z/OS.


Симптомы заболевания

Что происходит на самом деле можно посмотреть в логах FFDC. Для узла сервер приложений пишет данные логи в каталог /wasv85config/CELL/NODE/AppServer/profiles/PROFILE/logs/ffdc/. Очень удобно отсортировать содержимое каталога по дате изменения файлов и смотреть последние измененные, иначе разобраться в каком файле находится актуальная информация довольно не просто. В нашем случае обращает на себя внимание следующая ошибка:



[6/30/15 7:01:44:582 GMT] FFDC Exception:com.ibm.websphere.management.exception.ConnectorException SourceId:com.ibm.ws.management.RoutingTable.Accessor.getConnector ProbeId:583 Reporter:com.ibm.ws.management.RoutingTable$Accessor@e153aa4c
com.ibm.websphere.management.exception.ConnectorException: ADMC0016E: The system cannot create a SOAP connector to connect to host HOST at port PORT.
at com.ibm.websphere.management.AdminClientFactory.createAdminClientPrivileged(AdminClientFactory.java:635)
at com.ibm.websphere.management.AdminClientFactory.access$000(AdminClientFactory.java:127)
at com.ibm.websphere.management.AdminClientFactory$1.run(AdminClientFactory.java:210)
...
Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: java.io.IOException: Exception during sslSocket.startHandshake: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty; targetException=java.lang.IllegalArgumentException: Error opening socket: java.io.IOException: Exception during sslSocket.startHandshake: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty]
at org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPConnection.java:475)
at org.apache.soap.rpc.Call.WASinvoke(Call.java:510)

Записи в логах FFDC на стороне менеджера развертывания во многом похожи:


[6/26/15 6:45:11:707 GMT] FFDC Exception:com.ibm.websphere.management.exception.ConnectorException SourceId:com.ibm.ws.management.RoutingTable.Accessor.getConnector ProbeId:583 Reporter:com.ibm.ws.management.RoutingTable$Accessor@b44063cd
com.ibm.websphere.management.exception.ConnectorException: ADMC0016E: The system cannot create a SOAP connector to connect to host HOST at port PORT.
at com.ibm.websphere.management.AdminClientFactory.createAdminClientPrivileged(AdminClientFactory.java:635)
at com.ibm.websphere.management.AdminClientFactory.access$000(AdminClientFactory.java:127)
at com.ibm.websphere.management.AdminClientFactory$1.run(AdminClientFactory.java:210)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.websphere.management.AdminClientFactory.createAdminClient(AdminClientFactory.java:206)
at com.ibm.ws.management.RoutingTable$Accessor.getConnector(RoutingTable.java:1102)
at com.ibm.ws.management.RoutingTable$Accessor.getConnector(RoutingTable.java:1218)
at com.ibm.ws.management.RoutingTable$Accessor.resetSession(RoutingTable.java:1264)
at com.ibm.ws.management.RoutingTable.addChild(RoutingTable.java:397)

Caused by: [SOAPException: faultCode=SOAP-ENV:Client; msg=Error opening socket: java.io.IOException: Exception during sslSocket.startHandshake: Received fatal alert: handshake_failure; targetException=java.lang.IllegalArgumentException: Error opening socket: java.io.IOException: Exception during sslSocket.startHandshake: Received fatal alert: handshake_failure]
at org.apache.soap.transport.http.SOAPHTTPConnection.send(SOAPHTTPConnection.java:475)

Ставим диагноз

Очевидно, что проблема заключается в невозможности установить защищенное соединение между менеджером развертывания и агентом узла по протоколу (HTTPS). Чтобы менеджер развертывания "доверял" агенту узла, в хранилище сертификатов truststore менеджера развертывания должен находиться корневой сертификат, которым подписан сертификат сервера агента узла. Аналогично, чтобы агент узла "доверял" менеджеру развертывания, в хранилище сертификатов truststore данного агента узла должен находиться корневой сертификат, которым подписан сертификат сервера менеджера развертывания.

Если мы говорим о WebSphere Application Server for z/OS, то хранилищами сертификатов как правило являются z/OS System Access Facility (SAF) Keyrings. Задать пути и параметры подключения к хранилищам сертификатов можно на странице Security -> SSL certificate and key management -> Key stores and certificates консоли управления сервера приложений.


Лечение

На рисунке выше видно, что для узла cznodeb используется хранилище сертификатов safkeyring:///WASKeyring.WSBCELL, созданное для экс-стендалон сервера приложений WebSphere Application Server. Более того, в моем случае данное хранилище сертификатов изначально было пустым. Так как все остальные сервера в ячейке используют хранилище сертификатов safkeyring:///WASKeyring.CZCELL, то и для узла cznodeb необходимо прописать ссылки на данное хранилище.


После сохранения и синхронизации изменений (синхронизация с узлом cznodeb по очевидным причинам работать не будет, поэтому необходимо вручную скопировать на него файл /wasv85config/CELL/DMGR/DeploymentManager/profiles/default/config/cells/CELL/security.xml) необходимо перезапустить агент узла cznodeb. Агент сможет подключиться к менеджеру развертывания и синхронизироваться, а менеджер развертывания сможет подключиться к агенту, о чем будет свидетельствовать яркая зеленая стрелочка напротив соответстветствующей строки в таблице System administration -> Node agents, Node agents.


Больше вам зеленых стрелочек в жизни. Оставайтесь на связи!

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

вторник, 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.

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