WebOTX Application ServerのJMSサーバとのコネクションに関して、次のすべての条件を満たす場合に、タイミングにより、JMSサーバでデッドロックが発生します。
- 次の計算式で求められる数を超えて接続したJMSクライアントが、JMSサーバとのコネクションをクローズする
wojms.jms.min_threads / 2 (デフォルトでは5)
(wojms.jms.min_threadsプロパティは、コネクションサービスが使用するスレッドプールの最小数で、デフォルトは10。コネクション毎に、2つのスレッドを使用する。)
- コネクションがクローズされてから約2分後に、JMSクライアントがJMSサーバへ接続要求を行う
- JMSサーバが、クローズされたコネクションが使用していたスレッドを、接続要求のあったコネクションに割り当てる
本事象が発生すると、接続要求を行ったJMSクライアントに、JMSサーバからの応答が届かず、javax.jms.ConnectionFactory#createConnection()等の呼び出しがストールし、新規に接続を行うことができなくなります。
ただし、既に接続済みのコネクションを利用したJMSメッセージの送受信処理には影響はありません。
JMSクライアントからの接続要求がストールした場合、下記の方法でJMSサーバのスレッドダンプを採取し、デッドロックの記録の有無により、本事象であるかを判断できます。
- スレッドダンプ採取コマンド
otxadmin> login --user admin --password **** --port (ポート番号)
otxadmin> invoke server.jms-service.dumpThreads
- スレッドダンプ出力先ファイル
(V9以前) ${INSTANCE_ROOT}/logs/wojms/std.log
(V10以降) ${INSTANCE_ROOT}/logs/jmq/std.log
- 出力内容
スレッドダンプの最後に、次のような、"jms_ACCEPT"スレッドと、"WOJMSTimerThread"スレッド間のデッドロックが記録されている場合は、本事象が発生している可能性があります。
Found one Java-level deadlock:
=============================
"jms_ACCEPT":
waiting to lock monitor xxxxx (object xxxxx, a com.nec.webotx.messaging.jmq.jmsserver.service.imq.OperationRunnable), which is held by "WOJMSTimerThread"
"WOJMSTimerThread":
waiting to lock monitor xxxxx (object xxxxx, a com.nec.webotx.messaging.jmq.jmsserver.util.pool.ThreadPool),
which is held by "jms_ACCEPT"