WebOTX
Webサーバは「Apache」、Webコンテナは「Tomcat」をベースに作られているNEC製Webサーバとのこと。
他NEC製品(TPBASE等)との連携を想定されていて機能が充実している。
日本語ドキュメントは充実していてWebからでも参照できるが、WebOTX自体が非常に高価(お試し版で学習するのもそれなりの環境は必要)。
- WebOTXクラスローダではまったこと [2016-07-10] new
- JenkinsとWebOTXの連携(自動デプロイ化) [2013-05-31]
- otxadminの速度改善(multimodeの勧め) [2013-07-13]
WebOTXクラスローダではまったこと
以下公式サイトにも説明が記載されているが、WebOTXは複雑なクラスローダ構造によって柔軟なシステム実装実現している。
・5.9.1. クラスローダの階層
その反面、JavaのClass.forName()などを使用すると、WebOTXクラスローダの内部でロック(排他)が発生してしまう(各クラスローダでロックする)。
そのため、Class.forName()を多用するAPI(例えば XMLEncoder)と非常に相性が悪く、性能劣化の原因となる。
なるべく、WebOTXクラスローダのクラス検索(Class.forNameなど)を呼ばないように実装することが性能改善に繋がる。
※ XMLEncoderは内部でjava.beans.PersistenceDelegateを使用しており、そこから呼ばれるInstanceFinderと呼ばれるクラスの内部でClass.forName()を大量に使用している。
その内部で、暗黙的に末尾にPersistenceDelegateやBeanInfoなどのクラスを探しに行くのだが、これが原因でClassNotFoundExceptionが大量に出るのも性能劣化の影響となる。
クラスローダのロックの原因として、WebOTXのJNI(共有メモリ等)の動きも怪しいが、そこはノーコメント(笑)。
JenkinsとWebOTXの連携(デプロイ自動化)
- JenkinsからWebOTXへ自動デプロイするための手順
- Jenkinsからは以下内容のジョブを作成する。
- 対象をビルドしてWARを作成
- FTPプラグインで作成したWARをアップロード
- SSHプラグインでデプロイシェル(後述)にWebOTXドメイン情報を引数としてキックする
- cron設定で定期実行する
*WebOTXのコマンドからのデプロイは「成功」「失敗」ともに標準出力のため、
上記を判断するためにシェルを使用している。#!/bin/sh # ログイン情報(引数から取得する) ADMIN_USERNAME=$1 ADMIN_PASSWORD=$2 ADMIN_PORT=$3 WAR_URL=$4 # 標準出力用のシェル名 MY_NAME=`basename $0` echo "[INFO] STARTING DEPLOY `date`(${MY_NAME}[${LINENO}])" # OTXADMIN OTXADMIN="/opt/WebOTX/bin/otxadmin" # ドメイン情報を設定 WEBOTX_LOGIN="--user ${ADMIN_USERNAME} --password ${ADMIN_PASSWORD} --host localhost --port ${ADMIN_PORT}" # デプロイした結果「標準出力」を取得 deployResult=`${OTXADMIN} deploy ${WEBOTX_LOGIN} --force ${WAR_URL}` resultValue=$? # ロードエラー時の出力が「標準出力」のため # 出力内容からエラーかどうかを判断する。 deployResult=`echo $deployResult | grep "load error"` if [ "$deployResult" != "" -o "$resultValue" != "0" ]; then echo "[ERROR] DEPLOY FAILED `date`(${MY_NAME}[${LINENO}])" # 失敗 exit 1 fi echo "[INFO] DEPLOY COMPLETED `date`(${MY_NAME}[${LINENO}])" # 成功 exit 0
otxadminの速度改善(multimodeの勧め)
WebOTX の otxadmin コマンドは以下モードがあるが
シェルやバッチ処理等で大量のコマンドを発行するときは「multimode」のほうがパフォーマンスが良い
- 対話型
- シングルモード
簡易コマンド実行時およびシェル等で使用する - マルチモード(multimode)
主にシェル等で使用する
# 対話型 /opt/WebOTX/bin/otxadmin otxadmin > [コマンド入力] # シングルモード(都度セッションを作成してコマンドを発行している) /opt/WebOTX/bin/otxadmin [コマンド] --user ${USERNAME} --password ${PASSWORD} --port ${PORT} [引数] # マルチモード(1つのセッション使ってコマンド発行しているため軽い) /opt/WebOTX/bin/otxadmin multimode --file [コマンドが書かれたファイル名] _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ [コマンド記述ファイルサンプル] login --user ${USERNAME} --password ${PASSWORD} --port ${PORT} set example1=example1_value set example2=example2_value set example3=example3_value logout # シェルから実行する場合は、必ずexitを記述する exit _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/*シェルからマルチモードでコマンドを発行する場合、終了時に exit を記述しないと、対話モードとなってしまい応答が帰ってこない。
また、何故か「コマンドが失敗した」場合、対話モード中は無限にリトライが走ってしまう?。
上記が原因で、「ライフサイクルモジュール」を実装して、 invoke でMOを設定するような仕組みとしたが、
コマンドファイル内の exit 記述が漏れており、「無限リトライが発生→ドメイン停止→停止中にinvokeコマンドが大量に発行」という現象が発生。
その結果、config配下の ライフサイクルモジュール設定の xml が壊れてしまいドメインが起動しないという問題が発生した。
→世代バックアップがあるので、そこから復旧したが。。。謎すぎる。