WebLogic JMS プログラマーズガイド

WebLogic Server の障害からの回復

以下の節では、ネットワーク障害の発生後にほとんどの JMS クライアントを自動的に更新する、JMS クライアントの再接続機能について解説し、サーバで障害が発生した場合に JMS アプリケーションを正常に終了させる方法、およびサーバ障害の発生後に JMS データを移行する方法について説明します。

JMS クライアントの自動フェイルオーバ

JMS クライアントの再接続機能を使用すると、ネットワーク障害の発生時に JMS クライアントオブジェクトを個別的、集合的に更新可能にすることで、自動的かつ透過的なフェイルオーバを行えます。ネットワーク接続の失敗の原因としては、一過性のもの (ネットワーク接続の一時的な中断) と一過性でないもの (サーバのバウンスまたはネットワーク障害) が考えられます。WebLogic Server 9.1 の場合、更新可能な JMS クライアントオブジェクトには、Destination、Connection、Session、MessageProducer などがあります。

WebLogic Server 9.1 では、ネットワーク障害が発生したときに WebLogic JMS クライアントコードで再接続が行われます (コードリスト 13-1 の手順 3 ～ 8 で再接続が行われます)。

コードリスト 13-1 メッセージ生成用の JMS クライアントコードのサンプル

0.   Context ctx = create WebLogic JNDI context with credentials etc.
1.   ConnectionFactory cf = ctx.lookup(JNDI name of connection factory)
2.   Destination dest     = ctx.lookup(JNDI name of destination)
     // 以下の処理がネットワーク障害から回復する
3.   Connection  con      = cf.createConnection()
4.   Session     sess     = con.createSession(no transactions, ack mode)
5.   MessageProducer prod = sess.createProducer(dest)
6.   Loop over:
7.      Message msg = sess.createMessage() 
8.      prod.send(msg)
9.   con.close(); ctx.close()

ネットワーク障害が発生した場合には、コードリスト 13-1 の手順 3 ～ 8 で再接続が試行されます。可能であれば、JMS クライアントは他のサーバインスタンスに透過的にフェイルオーバします。これにより、クライアントコードは上記のように単純な記述のまま保持され、ネットワーク障害の時点で再試行するクライアントコードは不要になりました。

接続ファクトリの更新

Weblogic Server 8.1 以降、JNDI を通じてルックアップされた ConnectionFactory オブジェクト (コードリスト 13-1 の手順 1 を参照) は、ネットワーク障害後に再度ルックアップすることなく再使用できます。このネットワーク障害には、JMS クライアント JVM と、それが JNDI ルックアップの一部として接続されているリモート WebLogic Server インスタンスとの間の障害の場合、または JMS クライアント JVM と、JMS クライアントが後で接続する同じクラスタ内の任意のリモート WebLogic Server インスタンスとの間の障害の場合があります。

送り先の更新

JNDI を通じてルックアップされた Destination オブジェクト (キューまたはトピック) (コードリスト 13-1 の手順 2 を参照) は、ネットワーク障害後に再度ルックアップすることなく再使用できます。このネットワーク障害には、クライアント JVM と、それが接続されている WebLogic Server インスタンスとの間の障害の場合、またはその WebLogic Server インスタンスと、実際に送り先をホストしている WebLogic Server インスタンスとの間の障害の場合があります。Destination オブジェクトは、その送り先をホストしている WebLogic Server インスタンスが再起動した後も引き続き使用できます。

接続の更新

JMS Connection オブジェクトは、クライアント JVM とリモート WebLogic Server インスタンスとの間の物理的なネットワーク接続に 1 対 1 でマップするために使用されます。JMS クライアントの再接続機能では、ConnectionFactory.createConnection() メソッドからクライアントが取得する JMS Connection オブジェクト (コードリスト 13-1 の手順 3 を参照) は、「一度に 1 対 1」の方式で物理的なネットワーク接続にマップされます。結果として、JMS クライアントは引き続き同じ Connection オブジェクトを使用している一方で、暗黙的なフェイルオーバの後、実際には異なる WebLogic Server インスタンスと通信している場合があります。

ネットワークが切断された後、接続が暗黙的に更新されると、接続から派生するすべてのオブジェクト (javax.jms.Session オブジェクト、javax.jms.MessageProducer オブジェクトなど) も暗黙的に更新されます。更新時には、サーバにアクセスする接続やその派生オブジェクトでのすべての同期処理 (producer.send()、connection.createSession() など) を、接続が更新されていないと判断される前に一定時間ブロックすることができます。この時間は、weblogic.jms.extension.WLConnection インタフェースの setReconnectBlockingMillis(long) メソッドによって制御されます。

再接続機能では、アプリケーションが connection.close() を呼び出すまで WebLogic Server インスタンスの ConnectionFactory オブジェクトへの再接続がバックグラウンドで試行され続けます。ReconnectBlockingMillis パラメータは、接続がバックグラウンドで再試行されているときに接続を使用しようとしている同期呼び出し側のタイムアウトです。

接続が更新される前に同期呼び出しがタイムアウトすると、暗黙的な再接続が行われない場合とまったく同じように動作します (同じ例外が送出されます)。つまり、同期呼び出しは再接続機能のない古くなった接続で呼び出された場合と同じように動作します。

その後、呼び出し側は同期呼び出しを単純に再試行するか (重複メッセージのようにサービスの品質は低くなるおそれがあります)、または接続のバックグラウンドでの再試行を終了する connection.close() を呼び出すかを決定できます。

更新される接続の特殊なケース

以下の節では、接続が更新されるときに発生する可能性のある特殊なケースについて説明します。

クライアント ID のある接続

ネットワーク障害またはサーバ障害が発生したときに JMS 接続に指定されたクライアント ID がある場合、その接続は自動的に更新されません。この制限の理由は下位互換性にあります。障害の後、同じ接続名で JMS 接続を再作成しようとする既存の JMS アプリケーションの中断が回避されるためです。ネットワーク障害に対して暗黙的なフェイルオーバも実行されると、アプリケーションによる接続の作成は重複したクライアント ID が原因で失敗します。

クローズされたオブジェクトは更新されない

アプリケーションが javax.jms.Connection.close()、javax.jms.Session.close() などを呼び出した場合、そのオブジェクトとその派生オブジェクトは更新されません。同様に、JMS クライアントの接続が管理上の理由で破棄された場合も、その接続は更新されません。

登録済み例外リスナのある接続

JMS 接続に登録済みのアプリケーション ExceptionListener がある場合、その ExceptionListener の onException() コールバックは接続が暗黙的に更新された場合でも呼び出されます。このコールバックは、アプリケーションコードにネットワーク切断イベントを通知します。JMS クライアントアプリケーションコードは通常、onException で connection.close() を呼び出しますが、再接続機能を使用する場合は connection.close() を呼び出さないように選択することもできます。登録済みの ExceptionListener も内部的に更新された接続に透過的に移行され、更新された接続で例外をリスンします。

複数の接続

同じ ConnectionFactory オブジェクトから作成された複数の JMS 接続がある場合、再接続機能の点では、各接続は他の接続とは関係なく動作します。各接続には独自の接続ステータス、接続再試行機能などがあります。

セッションの更新

「接続の更新」で説明したように、JMS Connection オブジェクトの一部である JMS Session オブジェクトは、JMS Connection が更新されると暗黙的に更新されます (コードリスト 13-1 の手順 4 を参照)。確認応答モード、トランザクションモードなどのセッションステートは、更新が発生するたびに保持されます。更新後も createMessageProducer() などの呼び出しに対して同じセッションオブジェクトを使用できます。

更新されるセッションの特殊なケース

以下の節では、セッションが更新されるときに発生する可能性のある特殊なケースについて説明します。

保留中のコミットまたはロールバックのあるトランザクションセッション

非トランザクション JMS セッションと同様に、JMS トランザクションセッションも自動的に更新されます。ただし、ネットワークの切断時にコミットまたはロールバックを保留しているセッションに送信または受信処理があった場合には、セッション更新後の最初のコミット呼び出しは javax.jms.TransactionRolledBackException を送出して失敗します。この原因は、JMS セッションのトランザクションがネットワークの更新にまたがっている場合に、そのトランザクションのコミットが、(アプリケーションコードから見て) 更新の前にトランザクションの一部として実行された処理を保証できないことにあります。

セッション更新後の送信や受信などの処理では例外は送出されません。例外が送出されるのは更新後の最初のコミットだけです。ただし、ネットワークの切断時に JMS セッションに保留中のトランザクション処理がなかった場合は、セッション更新後の最初のコミットでも例外は送出されません。Session.commit() で例外が送出されると、クライアントアプリケーションコードでは再度同じ (暗黙的に更新された) JMS オブジェクトを使用するトランザクションですべての処理を単純に再試行できます。

保留中の未応答メッセージ

セッションの更新前にセッションに未応答メッセージがあった場合、更新後の最初の WLSession.acknowledge() 呼び出しでは weblogic.jms.common.LostServerException が送出されます。これは、acknowledge() 呼び出しによってメッセージがサーバからまだ削除されていない可能性があることを示します。その結果として、更新されたセッションは重複メッセージを受信するおそれがあります。

プロデューサオブジェクトの更新

(JMS Session を通じて) JMS Connection オブジェクトの一部である JMS Producer オブジェクトは、JMS Connection が更新されると暗黙的に更新されます (コードリスト 13-1 の手順 5 を参照)。

再接続の制限

以下のオブジェクトの暗黙的な更新は、WebLogic Server 9.1 ではサポートされていません。

javax.jms.MessageConsumer
javax.jms.QueueBrowser
一時的な送り先 : javax.jms.TemporaryQueue および javax.jms.TemporaryTopic
WebLogic JMS シンクライアント (詳細については、『スタンドアロンクライアントプログラマーズガイド』の「WebLogic JMS シンクライアント」を参照)
再接続ごとにリセットされるクライアントの統計 (結果としてクライアントの履歴データは失われます)

プログラムによる自動再接続の無効化

自動的な再接続を行わないアプリケーションでは、次のコードを呼び出す必要があります。

ConnectionFactory cf = javax.jms.ConnectionFactory)ctx.lookup(JNDI name of connection factory)
javax.jms.Connection con = cf.createConnection();
((weblogic.jms.extensions.WLConnection)con).setReconnectPolicy("none")

WebLogic Server 9.0 以前のリリースでの障害に関するプログラミングの考慮事項

WebLogic Server 9.0 以前のリリースで実行される JMS クライアントアプリケーションでは、サーバ障害の後に javax.jms オブジェクトを再確立する必要がありました。9.0 以前のリリースの JMS クライアントを実行している場合は、サーバ障害の発生時に正常に終了するよう、JMS クライアントをプログラミングすることもできます。次に例を示します。

表 13-1 サーバ障害に関するプログラミングの考慮事項

WebLogic Server インスタンスの障害発生時の状態	対応
障害が発生した WebLogic Server インスタンスに接続していた。	`JMSException` が接続例外リスナに配信される。サーバを再起動または交換したらすぐに、アプリケーションを再起動する必要がある。
障害が発生した WebLogic Server インスタンスが JMS サーバの対象になっていた。	`ConsumerClosedException` がセッション例外リスナに配信される。失われたすべてのメッセージコンシューマを再確立する必要がある。

新しいサーバへの JMS データの移行

WebLogic JMS では、WebLogic Server のコアに実装される移行フレームワークを使用します。これにより、WebLogic JMS は移行リクエストに正しく応答できるようになり、WebLogic JMS サーバのオンラインとオフラインの切り替えが順序立って行われるようになります。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への応答としての移行も含まれます。

いったん適切にコンフィグレーションすると、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server へ移行できます。

新しくサーバを起動し、表 13-2 のタスクのうち 1 つ以上を実行することで、障害が発生した WebLogic Server から JMS データを回復できます。

注意 : クラッシュしているか、管理サーバからアクセスできないサーバインスタンスからサービスを移行するときには、特別な考慮事項があります。移行を実行する時点で、以前アクティブだったサービスのホストに管理サーバからアクセスできない場合は、『WebLogic Server クラスタユーザーズガイド』の「現在アクティブなホストがない場合のサービスの移行」を参照してください。

表 13-2 移行タスクガイド

JMS アプリケーションで使用している機能	実行するタスク
永続的なメッセージング - JDBC ストア	障害が発生したサーバに JDBC データベースストアが存在している場合は、データベースを新しいサーバに移行し、JDBC 接続プールの URL 属性が適切なロケーション参照を反映していることを確認する。障害が発生したサーバに JDBC データベースストアが存在していない場合は、データベースへのアクセスに影響はないので、変更は不要。
永続的なメッセージング - ファイルストア	ファイルを新しいサーバに移行し、WebLogic Server ホームディレクトリ内のファイルのパス名が元のサーバにあったパス名と同じであることを確認する。
トランザクション	クラッシュ後の回復を容易にするために、WebLogic Server ではトランザクション回復サービスが提供されている。このサービスによりシステムの起動時にトランザクションの回復が自動的に試行される。トランザクション回復サービスでは、サーバのトランザクションのログが記録される。障害の発生したサーバからトランザクションを回復する手順の詳細については、『WebLogic JTA プログラマーズガイド』の「サーバに障害が発生した後のトランザクションの回復」を参照。

JMS アプリケーションで使用している機能

実行するタスク

永続的なメッセージング - JDBC ストア

障害が発生したサーバに JDBC データベースストアが存在している場合は、データベースを新しいサーバに移行し、JDBC 接続プールの URL 属性が適切なロケーション参照を反映していることを確認する。

障害が発生したサーバに JDBC データベースストアが存在していない場合は、データベースへのアクセスに影響はないので、変更は不要。

永続的なメッセージング - ファイルストア

ファイルを新しいサーバに移行し、WebLogic Server ホームディレクトリ内のファイルのパス名が元のサーバにあったパス名と同じであることを確認する。

トランザクション

クラッシュ後の回復を容易にするために、WebLogic Server ではトランザクション回復サービスが提供されている。このサービスによりシステムの起動時にトランザクションの回復が自動的に試行される。トランザクション回復サービスでは、サーバのトランザクションのログが記録される。

障害の発生したサーバからトランザクションを回復する手順の詳細については、『WebLogic JTA プログラマーズガイド』の「サーバに障害が発生した後のトランザクションの回復」を参照。

注意 : JMS 永続ストアに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープサイズを、現在 JMS 永続ストアに格納されているメッセージ数に比例するよう増加させてから、再起動してください。

新しく WebLogic Server を起動する方法の詳細については、「サーバの起動と停止 : クイックリファレンス」を参照してください。障害が発生したサーバの回復については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。

移行可能サービスの定義の詳細については、『WebLogic Server クラスタユーザーズガイド』の「サービスの移行」を参照してください。