TOP > 技術メモ > WebOTX

WebOTX

Webサーバは「Apache」、Webコンテナは「Tomcat」をベースに作られているNEC製Webサーバとのこと。
他NEC製品(TPBASE等)との連携を想定されていて機能が充実している。
日本語ドキュメントは充実していてWebからでも参照できるが、WebOTX自体が非常に高価(お試し版で学習するのもそれなりの環境は必要)。

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からは以下内容のジョブを作成する。
  1. 対象をビルドしてWARを作成
  2. FTPプラグインで作成したWARをアップロード
  3. SSHプラグインでデプロイシェル(後述)にWebOTXドメイン情報を引数としてキックする
  4. 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 が壊れてしまいドメインが起動しないという問題が発生した。
→世代バックアップがあるので、そこから復旧したが。。。謎すぎる。

▲ページの先頭へ