| Oracle® Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド 11g リリース 1 (10.3.1) B55536-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server JMS プログラマーズ ガイド 11g リリース 1 (10.3.1) B55536-01 |
|
戻る |
次へ |
以下の節では、サーバやネットワークの障害発生時に WebLogic JMS クライアント アプリケーションが再接続または回復する方法、および障害後に JMS データを移行する方法について説明します。
JMS クライアントの自動再接続機能では、サーバまたはネットワークに障害が発生した場合でも、一部の JMS クライアント オブジェクトは、使用可能な他のサーバ インスタンスがある限りそのサーバ インスタンスに透過的にフェイルオーバします。たとえば、致命的なサーバ障害が発生した場合、サーバが使用可能な状態になると JMS クライアントが自動的に再接続を試みます。
ネットワーク接続の失敗の原因としては、一過性のもの (ネットワーク接続の一時的な中断) と一過性でないもの (サーバのバウンスまたはネットワーク障害) が考えられます。これらの場合、一部の JMS クライアント オブジェクトは、クラスタ内の他のサーバ インスタンス (可能であればホスト サーバ) での稼動を自動的に試みます。
デフォルトでは、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、JMS プロデューサ セッション オブジェクトが自動的に使用可能なサーバ インスタンスに再接続しようとします。JMS プロデューサが自動的に再接続しないようにするには、プログラムまたは管理機能を使用して、この機能を明示的に無効にする必要があります。
また、JMS コンシューマ セッション オブジェクトが自動的に使用可能なサーバに再接続するようにコンフィグレーションすることもできます。ただし、JMS コンシューマ セッション オブジェクトは本質的に非同期オブジェクトであるため、Administration Console または公開されている WebLogic JMS API を使用して、この機能を明示的に有効にする必要があります。
詳細については、以下の節を参照してください。
ほとんどの場合、JMS プロデューサ アプリケーションは、使用可能な他のサーバ インスタンスがあれば透過的にフェイルオーバします。以下に示す WebLogic JMS プロデューサ指向のオブジェクトは、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、使用可能なサーバ インスタンスへの再接続を自動的に試みます。
Connection
Session
MessageProducer
JMS クライアントが自動的に再接続しないようにするには、プログラムまたは管理機能を使用して、この機能を明示的に無効にする必要があります。詳細については、「JMS クライアントの自動フェイルオーバを明示的に無効にする」を参照してください。
ネットワーク障害が発生すると、メッセージ生成用の WebLogic JMS クライアント コードによって、使用可能なサーバへの再接続が試行されます (コード リスト 14-1 の手順 3 ～ 8 を参照)。
コード リスト 14-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()
JMS プロデューサは、使用可能な他のサーバ インスタンスがあれば透過的にフェイルオーバします。これにより、クライアント コードは上記のように単純な記述のまま保持され、ネットワーク障害の時点で再試行するクライアント コードは不要になりました。
WebLogic JMS のデフォルトでは、MessageConsumer は再接続されません。MessageConsumer がプログラム的に再接続されるようにするには、setReconnectPolicy を "all" に設定した WebLogic WLConnection 拡張をクライアント アプリケーション コードから呼び出す必要があります。詳細については、「JMS コンシューマの自動フェイルオーバのコンフィグレーション」を参照してください。
WebLogic Server 8.1 以降、JNDI でルックアップされた ConnectionFactory オブジェクト (コード リスト 14-1 およびコード リスト 14-2 の手順 1 を参照) は、サーバまたはネットワークの障害後に再度ルックアップすることなく再使用できます。ネットワーク障害には、JMS クライアント JVM と、それが JNDI ルックアップの一部として接続されているリモート WebLogic Server インスタンスとの間の障害の場合、または JMS クライアント JVM と、JMS クライアントが後で接続する同じクラスタ内の任意のリモート WebLogic Server インスタンスとの間の障害の場合があります。
JNDI でルックアップされた Destination オブジェクト (キューまたはトピック。コード リスト 14-1 およびコード リスト 14-2 の手順 2 を参照) は、サーバまたはネットワークの障害後に再度ルックアップすることなく再使用できます。この点は、分散送り先への送信を行うプロデューサの場合も同様です。クライアントは、JNDI で分散送り先をルックアップし、使用不能な分散メンバーはルックアップされないためです。
ネットワーク障害には、クライアント JVM と、それが接続されている WebLogic Server インスタンスとの間の障害の場合、またはその WebLogic Server インスタンスと、実際に送り先をホストしている WebLogic Server インスタンスとの間の障害の場合があります。Destination オブジェクトは、その送り先をホストしている WebLogic Server インスタンスが再起動した後も引き続き使用できます。
JMS Connection オブジェクトは、クライアント JVM とリモート WebLogic Server インスタンスとの間の物理的なネットワーク接続に 1 対 1 でマップするために使用されます。JMS クライアントの再接続機能では、ConnectionFactory.createConnection() メソッドからクライアントが取得する JMS Connection オブジェクト (コード リスト 14-1 およびコード リスト 14-2 の手順 3 を参照) は、「一度に 1 対 1」の方式で物理的なネットワーク接続にマップされます。結果として、JMS クライアントは引き続き同じ Connection オブジェクトを使用している一方で、暗黙的なフェイルオーバの後、実際には異なる WebLogic Server インスタンスと通信している場合があります。
ネットワークが切断された後、接続が暗黙的に更新されると、その接続から派生するすべてのオブジェクト (javax.jms.Session オブジェクト、javax.jms.MessageProducer オブジェクトなど) も暗黙的に更新されます。更新時には、サーバにアクセスする接続やその派生オブジェクトでのすべての同期処理 (producer.send()、connection.createSession() など) を、接続が更新されていないと判断される前に一定時間ブロックすることができます。この時間は、Administration Console を使用してコンフィグレーションするか、weblogic.jms.extension.WLConnection インタフェースの setReconnectBlockingMillis(long) API を使用してコンフィグレーションします。
再接続機能では、アプリケーションが connection.close() を呼び出すまで、WebLogic Server インスタンスの ConnectionFactory オブジェクトへの再接続がバックグラウンドで試行され続けます。ReconnectBlockingMillis パラメータは、接続がバックグラウンドで再試行されているときに接続を使用しようとしている同期呼び出し側のタイムアウトです。
接続が更新される前に同期呼び出しがタイムアウトすると、暗黙的な再接続が行われない場合とまったく同じように動作します (同じ例外が送出されます)。つまり、同期呼び出しは再接続機能のない古くなった接続で呼び出された場合と同じように動作します。
その後、呼び出し側は同期呼び出しを単純に再試行するか (重複メッセージのようにサービスの品質は低くなるおそれがあります)、または接続のバックグラウンドでの再試行を終了する connection.close() を呼び出すかを決定できます。
以下では、プロデューサ接続が更新されるときに発生する可能性のある特殊なケースについて説明します。
恒久サブスクライバの ClientID が指定されている Connection - [再接続ポリシー] フィールドが [なし] または [プロデューサ] に設定されている場合、ネットワークまたはサーバの障害が発生したときに JMS Connection に ClientID が指定されていると、その Connection は自動的には更新されません。この制限の理由は下位互換性にあります。障害の後、同じ接続名で JMS Connection を再作成しようとする既存の JMS アプリケーションが中断されるのを回避するためです。ネットワーク障害に対して暗黙的なフェイルオーバも実行されると、アプリケーションによる接続の作成は重複した ClientID が原因で失敗します。
クローズされたオブジェクトは更新されない - アプリケーションが javax.jms.Connection.close()、javax.jms.Session.close() などを呼び出した場合、そのオブジェクトとその派生オブジェクトは更新されません。同様に、JMS クライアントの Connection が管理上の理由で破棄された場合も、その Connection は更新されません。
例外リスナが登録されている Connection - JMS Connection にアプリケーションの ExceptionListener が登録されている場合、その ExceptionListener の onException() コールバックは接続が暗黙的に更新された場合でも呼び出されます。このコールバックは、アプリケーション コードにネットワーク切断イベントを通知します。JMS クライアント アプリケーション コードは通常、onException で connection.close() を呼び出しますが、再接続機能を使用する場合は connection.close() を呼び出さないように選択することもできます。登録済みの ExceptionListener も内部的に更新された接続に透過的に移行され、更新された接続で例外をリスンします。
複数の Connection - 同じ ConnectionFactory オブジェクトから作成された複数の JMS Connection がある場合、再接続機能の点では、各接続は他の接続とは関係なく動作します。各接続には独自の接続ステータス、接続再試行機能などがあります。
「再接続される Connection オブジェクト」で説明したように、JMS Connection に関連付けられている JMS Session オブジェクトは更新されます (コード リスト 14-1 およびコード リスト 14-2 の手順 4 を参照)。確認応答モード、トランザクション モードなどのセッション ステートは、更新が発生するたびに保持されます。更新後も createMessageProducer() などの呼び出しに対して同じセッション オブジェクトを使用できます。
以下では、Session が再接続されるときに発生する可能性のある特殊なケースについて説明します。
保留中のコミットまたはロールバックのあるトランザクション セッション - 非トランザクション JMS Session と同様に、JMS トランザクション セッションも自動的に更新されます。ただし、ネットワークの切断時にコミットまたはロールバックを保留している Session に送信または受信処理があった場合には、Session 更新後の最初のコミット呼び出しは javax.jms.TransactionRolledBackException を送出して失敗します。JMS Session のトランザクションがネットワークの更新にまたがっている場合、そのトランザクションのコミットは (アプリケーション コードから見て) 更新の前にトランザクションの一部として実行された処理を保証できません。
Session 更新後の send() や receive() などの処理では例外は送出されません。例外が送出されるのは更新後の最初のコミットだけです。ただし、ネットワークの切断時に JMS Session に保留中のトランザクション処理がなかった場合は、Session 更新後の最初のコミットでも例外は送出されません。Session.commit() で例外が送出されると、クライアント アプリケーション コードでは再度同じ (暗黙的に更新された) JMS オブジェクトを使用するトランザクションですべての処理を単純に再試行できます。更新前の古くなった処理は、コミットも複製もされません。
保留中の未応答メッセージ - Session の更新前にセッションに未応答メッセージがあった場合、更新後の最初の WLSession.acknowledge() 呼び出しで weblogic.jms.common.LostServerException が送出されます。これは、acknowledge() 呼び出しによってメッセージがサーバからまだ削除されていない可能性があることを示します。その結果、更新された Session が切断前に配信されたメッセージを重複して受信するおそれがあります。
「再接続される Connection オブジェクト」で説明したように、JMS Connection に関連付けられている JMS MessageProducer オブジェクトは更新されます (コード リスト 14-1 の手順 5 を参照)。プロデューサが非匿名である場合、つまり、特定の Destination オブジェクト (スタンドアロンの送り先または分散送り先) 専用である場合は、そのプロデューサの送り先も暗黙的に更新されます (「再使用可能な Destination オブジェクト」を参照)。プロデューサが匿名である場合 (つまり、特定の Destination オブジェクト専用でない場合) は、そのプロデューサの send() 処理で指定されている古くなった可能性のある Destination オブジェクトが暗黙的に更新されます。
分散送り先メンバーが使用不能になるのと同時に、プロデューサがメッセージを送信する可能性もあります。WebLogic JMS では、分散送り先メンバーが使用不能であることを検知したり、メッセージを送信したときに使用不能だったことが検出されると、システムが別の分散メンバーへのメッセージの送信を再試行します。ただし、分散メンバーが使用不能になる前にメッセージが届いたかどうかを確認できない場合は、メッセージが重複して作成されるおそれがあるため再送は行われません。この場合は例外が送出されます。その例外を捕捉してメッセージを再送するかどうかを決めるのはアプリケーションの役割です。
JMS Session を通じて JMS Connection オブジェクトの一部になっている JMS MessageConsumer オブジェクトは、JMS 接続の更新中に更新できます (コード リスト 14-2 の手順 5 を参照)。ただし、JMS コンシューマはステートフルで本質的に非同期なオブジェクトであるため、weblogic.jms.extension.WLConnection API または Administration Console を使用してこの機能を明示的に有効にする必要があります。
コンシューマの自動更新を明示的に有効にすると、恒久サブスクライバの ClientID がコンフィグレーションされている接続も更新されます (「恒久サブスクリプションの ClientID が指定されたコンシューマ接続」を参照)。ただし、更新されたコンシューマには QueueBrowser クライアントは含まれません。「JMS クライアントの自動フェイルオーバの制限事項」で説明するように、QueueBrowser クライアントは更新されることのないクライアントです。
メッセージ コンシューマの更新を明示的に有効にした場合、ネットワーク障害が発生すると、メッセージ消費用の WebLogic JMS クライアント コードによって再接続が試行されます (コード リスト 14-2 の手順 3 ～ 8 を参照)。
コード リスト 14-2 メッセージ消費用の 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()
(weblogic.jms.extensions.WLConnection)con).setReconnectPolicy("all")
4. Session sess = con.createSession(no transactions, auto ack)
5. MessageConsumer cons = sess.createConsumer(dest, message selector)
- also for async consumers : cons.setMessageListener(onMessage impl)
6. con.start()
7. Loop over:
for sync consumers: Message msg = consumer.receive()
for async consumers (in different thread): onMessage() invoked
8. con.close(), ctx.close()
なお、デフォルトでは、接続ファクトリは MessageConsumer オブジェクトを更新しません。MessageConsumer がプログラム的に更新されるようにするには、setReconnectPolicy を "all" に設定した WebLogic WLConnection 拡張をクライアント アプリケーション コードから呼び出す必要があります (コード リスト 14-2 の手順 3 を参照)。
JMS クライアント再接続 API には、以下のコンフィグレーション パラメータが含まれています。これらのパラメータを使用して、コンシューマの再接続機能の動作を制御できます。
表 14-1 JMS クライアントの自動再接続オプション
| フィールド名/MBean 属性 | 値 | 説明 |
|---|---|---|
|
[再接続ポリシー] ReconnectPolicy |
|
ネットワークの切断時やサーバの再起動時に、どの JMS クライアント オブジェクトを暗黙的に更新するかを指定する。この属性は、この ConnectionFactory から派生した Connection、Session、Producer、および Consumer の暗黙的な更新にのみ適用される。JMS クライアント内の Destination オブジェクトや ConnectionFactory オブジェクトは、常に暗黙的に更新されるため適用外。また、JMS クライアント内の QueueBrowser も、更新されることのないオブジェクトであるため適用外。 |
|
[再接続ブロッキング時間] ReconnectBlockingTimeMillis |
6000 |
任意の同期 JMS 呼び出し ( |
TotalReconnectPeriodMillis |
-1 |
ネットワークの最初の中断、または同期 JMS 呼び出しの最後の試行のいずれかが起きた後、JMS クライアントがサーバへの再接続を再試行し続ける時間 (再試行をあきらめるまでの時間) を指定する。 |
Administration Console を使用して接続ファクトリのクライアント パラメータをコンフィグレーションする手順については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続ファクトリのクライアント パラメータのコンフィグレーション」を参照してください。これらのパラメータの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「ClientParamsBean」を参照してください。
この節では、同期および非同期コンシューマを更新する一般的なケースについて説明します。
同期コンシューマは、MessageConsumer.receive()、MessageConsumer.receive(timeout)、および MessageConsume.receiveNoWait() メソッドを使用してメッセージを消費します。1 番目と 2 番目のメソッドではアプリケーション コードをブロックする可能性が想定されていますが、3 番目のメソッドではアプリケーション コードのブロックは想定されていません。これらのセマンティクスを維持するため、同期コンシューマ呼び出しでの再接続機能の対話には以下のルールが適用されます。
MessageConsumer.receive()- この呼び出しの場合は、呼び出しの間に切断されたネットワークがあると、再接続を試行するためにアプリケーション コードがブロックされます。例外が送出されるまでの時間は、コンフィグレーション セクションにある [再接続ブロッキング時間] プロパティの値が最大値となります。
MessageConsumer.receive(timeout) - この呼び出しの場合は、呼び出し側によって指定されたタイムアウトを最大値としてアプリケーション コードがブロックされます。[再接続ブロッキング時間] プロパティがタイムアウトより短い場合は、[再接続ブロッキング時間] が最大値となります。一方、[再接続ブロッキング時間] プロパティがタイムアウトより長い場合はタイムアウトが最大値となります。
MessageConsumer.receiveNoWait() - この呼び出しの場合は、JMS Connection による再接続処理中もアプリケーション コードはブロックされません。[再接続ブロッキング時間] は、この呼び出しには適用されません。
これらのメソッドがそれぞれのタイムアウト/待機時間に達すると、再接続されることなく同じ例外が送出されます。これらのメソッドのブロックまたは呼び出しの間に再接続に成功した場合は、引き続きメソッドからメッセージが返されます。ただし、回復後は、サービスの品質 (QOS) が低下したり、似たようなセマンティクスでのメッセージ受信 (たとえばメッセージの再配信) が発生したりする可能性があります。このような可能性は、Connection ExceptionListener コールバックによる LostServerException によってアプリケーションに通知されます。また、確認応答モードが AUTO_ACK 以外の場合は、更新後の最初の確認応答呼び出しによって送出される LostServerException でアプリケーションに通知されます。
再接続のコンテキストでは、非同期コンシューマの動作は [再接続の合計期間] プロパティの設定によって制御されます。[再接続の合計期間] プロパティに設定されている時間内に再接続が成功した場合は、JMS Consumer に登録されているメッセージ リスナの onMessage() が引き続き呼び出されます。ユーザが JMS Connection (または、非同期の Consumer に対応する JMS Session) に対して明示的に close() を呼び出した場合は、その Consumer に対する onMessages はそれ以降呼び出されません。Connection ExceptionListener の onException が LostServerException で呼び出された場合に備え、onMessage() において回復後の動作 (たとえばメッセージの再配信) を想定しておく必要があります。
以下の節では、コンシューマが更新されるときに発生する可能性のある特殊なケースについて説明します。
WebLogic Server 9.2 より前のリリースでは、分散送り先のコンシューマは、その生存時間中は特定の送り先メンバーに固定されていました。これが当てはまるのは、分散キューのキュー コンシューマと、分散トピックの非恒久サブスクライバです (恒久サブスクライバでは分散トピックはサポートされません)。
MessageConsumer の再接続時には、分散送り先コンシューマも更新されます。しかし、更新されたコンシューマが、古くなったコンシューマと同じ送り先を使用することはほとんどありません。つまり、アプリケーションでは更新前と同じ分散送り先コンシューマを使用していても、そのコンシューマが更新前と同じ送り先メンバーに固定されているわけではありません。
メッセージ駆動型 EJB (MDB) は非同期コンシューマの一種で、独自の動作要件と更新フレームワークを備えています。そのため、MessageConsumer の更新に参加することは想定されておらず、他のどの方法によっても JMS クライアント再接続フレームワークの影響を受けることはありません。
スタンドアロン トピックの恒久サブスクリプションは、切断後の再接続によってトピックが使用可能になれば、クライアント再接続機能で生じた違いに関係なく機能します。JMS クライアント再接続フレームワークでは、そのトピックの恒久サブスクライバが暗黙的に更新され、中断された位置から継続されます。なお、[再接続ポリシー] が [すべて] に設定されている場合は、ClientID が指定された JMS Connection も自動的に更新されるため、ClientID によってスコープが指定されている恒久サブスクリプションを自動的に更新することは可能です。ClientID が指定された Connection は、それ以外の [再接続ポリシー] 設定では再接続されません。
|
注意 : ネットワークまたはサーバの障害が発生したときに JMS 接続に ClientID が指定されている場合、そのクライアントの再接続にかかる時間は他のクライアントに比べてかなり長くなる場合があります。たとえば、クラスタ内の JMS サーバは、クラスタの他のメンバーからブロードキャストされる WebLogic Server の「ハートビート」通知を待機する必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「クラスタのフェイルオーバとレプリケーション」を参照してください。WebLogic JMS では、分散トピックでの恒久サブスクリプションはサポートされていません。したがって、更新時の別の分散トピック メンバーへのフェイルオーバは問題にはなりません。 |
コンシューマがトピックの非恒久サブスクライバである場合、アプリケーションからは更新後も問題なく消費が行われているように見えても、トピックにパブリッシュされたメッセージが、コンシューマの不足などが原因で再接続中に破棄されている可能性があります。このようなメッセージの破棄は、同期非恒久サブスクライバでも非同期恒久サブスクライバでも発生します。
コンシューマの更新機能の性質上、クライアント アプリケーション コードから明示的に回復を呼び出さなくても、メッセージの再配信が発生する可能性があります。これは、コンシューマを更新すると、暗黙的に回復と同等の効果が生じるためです。これが、暗黙的なコンシューマの更新がデフォルトで有効になっていない主な理由です。なお、この場合でも、問題なく確認応答されたメッセージが再配信されることはありません。
また、これも稀なケースですが、分散トピックの非恒久サブスクライバが、再配信とマークされていない重複メッセージを受信することもあります (たとえば、トピック内でメッセージが破棄されるより前にフェイルオーバが発生した場合)。これは、更新の前後で特定のトピック メンバーに固定されていない分散トピックの非恒久サブスクライバを更新した結果として発生します。
確認応答モードの違いが原因で、コンシューマの再接続動作に差異が生じることはありません。ただし、すでに説明したように、AUTO_ACK 以外の確認応答モードでは、サービスの品質が低下した可能性があることをアプリケーションに通知するため、更新後の最初の確認応答呼び出しで LostServerException が送出されます。
JMS クライアントが自動的に再接続しないようにするには、プログラムまたは管理機能を使用して、この機能を明示的に無効にする必要があります。
プログラムを使用して 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.jms.extension.WLConnection API の setReconnectPolicy メソッドを参照してください。
管理機能を使用して JMS クライアントが自動的に再接続しないようにするには、次の手順に従って JMS 接続ファクトリの [再接続ポリシー] を無効にします。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプにある「接続ファクトリのクライアント パラメータのコンフィグレーション」の説明に従って、[JMS 接続ファクトリ : コンフィグレーション : クライアント] ページに移動します。
選択した接続ファクトリで JMS クライアントの再接続機能を無効にするには、[再接続ポリシー] フィールドで [なし] を選択します。
[再接続ポリシー] フィールドの詳細については、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : クライアント」を参照してください。
[保存] をクリックします。
その他の JMS 接続ファクトリ クライアント パラメータの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server MBean Reference』の「ClientParamsBean」を参照してください。
以下の JMS オブジェクトの暗黙的なフェイルオーバは、WebLogic Server 9.2 ではサポートされていません。
キュー ブラウザ (javax.jms.QueueBrowser)。
WebLogic JMS シン クライアント (wljmsclient.jar) は、自動的には再接続されない。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server スタンドアロン クライアント プログラマーズ ガイド』の「WebLogic JMS シン クライアント」を参照してください。
再接続ごとにリセットされるクライアントの統計 (結果としてクライアントの履歴データは失われます)。
一時的な送り先 (javax.jms.TemporaryQueue および javax.jms.TemporaryTopic)。
|
ヒント : サーバやネットワークに障害が発生した後でも、一時的な送り先にアクセスできることがあります。これは、サーバのロード バランシングの結果として、一時的な送り先が常にローカル接続ファクトリと同じサーバ インスタンスにあるとは限らないためです。したがって、サーバやネットワークに障害が発生した後も一時的な送り先にアクセスでき、プロデューサからのメッセージが引き続き送信されている場合、自動的に再接続されたコンシューマが、障害前に接続されていたのと同じ一時送り先からのメッセージを消費できるかどうかは分かりません。 |
Oracle では、JMS クライアントの自動再接続機能を使用する場合のベスト プラクティスとして以下を推奨しています。
関連する作業や依存関係にある作業 (メッセージング作業を含む) は、トランザクション セッション (JMS) またはユーザ トランザクション (JTA) を使用してグループ化することをお勧めします。このようにすると、すべての作業が完了しているか、すべての作業が完了していないか、どちらかの状態になります。サーバ インスタンスに障害が発生して転送中のメッセージが消失しても、トランザクション全体をロールバックすれば、障害後に各メッセージをどのように処理するかをアプリケーションで判断する必要はありません。
|
ヒント : サーバの再接続後は、トランザクションのコミットの失敗に注意してください。トランザクション サブシステムがトランザクションに関係するすべての参加者にアクセスできないと、トランザクションのコミットに失敗することがあります。 |
ベスト プラクティスとして、アプリケーションでは JVM ガベージ コレクションを使用して JMS 接続をクリーンアップしないことをお勧めします。これは、JMS 自動再接続機能では JMS 接続への参照が保持されるためです。したがって、常に connection.close() を使用して接続をクリーンアップします。また、接続リソースを確実にクリーンアップするため、Finally ブロックを使用することも検討してください。このようにしない場合、接続を使用可能な状態に維持するためにシステム リソースが割り当てられてしまいます。
JMS クライアント接続を閉じることに関する詳細については、「ベスト プラクティス : 問題が発生した JMS ClientID は常に閉じる」を参照してください。
WebLogic Server 9.0 以前のリリースで実行される JMS クライアント アプリケーションでは、サーバ障害の後に javax.jms オブジェクトを再確立する必要がありました。9.0 以前のリリースの JMS クライアントを実行している場合は、サーバ障害の発生時に正常に終了するよう、JMS クライアントをプログラミングすることもできます。次に例を示します。
WebLogic JMS では、移行フレームワークを使用することによって、WebLogic JMS が移行リクエストに正しく応答できるようになり、WebLogic JMS サーバのオンラインとオフラインの切り替えが順序立って行われるようになります。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への応答としての移行も含まれます。
いったん適切にコンフィグレーションすると、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server へ移行できます。
新しくサーバを起動し、表 14-3 のタスクのうち 1 つ以上を実行することで、障害が発生した WebLogic Server から JMS データを回復できます。
|
注意 : クラッシュした、または管理サーバからアクセスできないサーバ インスタンスからサービスを移行する場合は、特別な考慮事項があります。移行を実行する時点で、以前アクティブだったサービスのホストに管理サーバからアクセスできない場合は、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「使用不能サーバからのサービスの移行」を参照してください。 |
表 14-3 移行タスク ガイド
| JMS アプリケーションで使用している機能 | 実行するタスク |
|---|---|
|
永続的なメッセージング - JDBC ストア |
|
|
永続的なメッセージング - ファイル ストア |
ファイルを新しいサーバに移行し、WebLogic Server ホーム ディレクトリ内のファイルのパス名が元のサーバにあったパス名と同じであることを確認する。 |
|
トランザクション |
クラッシュ後の回復を容易にするため、WebLogic Server ではトランザクション回復サービスを提供している。このサービスでは、システムの起動時にトランザクションの回復が自動的に行われる。トランザクション回復サービスでは、サーバのトランザクションのログが記録される。 障害の発生したサーバからトランザクションを回復する手順の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「サーバに障害が発生した後のトランザクションの回復」を参照。 |
|
注意 : JMS 永続ストアに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストアに格納されているメッセージ数に比例するよう増加させてから、再起動してください。 |
新しく WebLogic Server を起動する方法の詳細については、「サーバの起動と停止 : クイック リファレンス」を参照してください。障害が発生したサーバの回復については、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。
移行可能サービスの定義の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「サービスの移行」を参照してください。
