|
|
以下の節では、サーバやネットワークの障害発生時に WebLogic JMS クライアント アプリケーションが再接続または回復する方法、および障害後に JMS データを移行する方法について説明します。
JMS クライアントの自動再接続機能では、サーバまたはネットワークに障害が発生した場合でも、一部の JMS クライアント オブジェクトは、使用可能な他のサーバ インスタンスがある限りそのサーバ インスタンスに透過的にフェイルオーバします。たとえば、致命的なサーバ障害が発生した場合、サーバが使用可能な状態になると JMS クライアントが自動的に再接続を試みます。
ネットワーク接続の失敗の原因としては、一過性のもの (ネットワーク接続の一時的な中断) と一過性でないもの (サーバのバウンスまたはネットワーク障害) が考えられます。これらの場合、一部の JMS クライアント オブジェクトは、クラスタ内の他のサーバ インスタンス (可能であればホスト サーバ) での稼動を自動的に試みます。
デフォルトでは、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、JMS プロデューサ セッション オブジェクトが自動的に使用可能なサーバ インスタンスに再接続しようとします。JMS プロデューサが自動的に再接続しないようにするには、プログラムまたは管理機能を使用して、この機能を明示的に無効にする必要があります。
また、JMS コンシューマ セッション オブジェクトが自動的に使用可能なサーバに再接続するようにコンフィグレーションすることもできます。ただし、JMS コンシューマ セッション オブジェクトは本質的に非同期オブジェクトであるため、Administration Console または公開されている WebLogic JMS API を使用して、この機能を明示的に有効にする必要があります。
ほとんどの場合、JMS プロデューサ アプリケーションは、使用可能な他のサーバ インスタンスがあれば透過的にフェイルオーバします。以下に示す WebLogic JMS プロデューサ指向のオブジェクトは、既存のクライアント コードを手動でコンフィグレーションまたは変更しなくても、使用可能なサーバ インスタンスへの再接続を自動的に試みます。
JMS クライアントが自動的に再接続しないようにするには、プログラムまたは管理機能を使用して、この機能を明示的に無効にする必要があります。詳細については、「JMS クライアントの自動フェイルオーバを明示的に無効にする」を参照してください。
ネットワーク障害が発生すると、メッセージ生成用の WebLogic JMS クライアント コードによって、使用可能なサーバへの再接続が試行されます (コード リスト 14-1 の手順 3 ～ 8 を参照)。
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 クライアントの自動再接続時に分散送り先のコンシューマがどのように動作するかについては、「分散送り先のコンシューマ」を参照してください。 |
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 が指定されているコンシューマ接続の動作については、「恒久サブスクリプションの ClientID が指定されたコンシューマ接続」を参照してください。 |
javax.jms.Connection.close()、javax.jms.Session.close() などを呼び出した場合、そのオブジェクトとその派生オブジェクトは更新されません。同様に、JMS クライアントの Connection が管理上の理由で破棄された場合も、その Connection は更新されません。onException() コールバックは接続が暗黙的に更新された場合でも呼び出されます。このコールバックは、アプリケーション コードにネットワーク切断イベントを通知します。JMS クライアント アプリケーション コードは通常、onException で connection.close() を呼び出しますが、再接続機能を使用する場合は connection.close() を呼び出さないように選択することもできます。登録済みの ExceptionListener も内部的に更新された接続に透過的に移行され、更新された接続で例外をリスンします。
「再接続される Connection オブジェクト」で説明したように、JMS Connection に関連付けられている JMS Session オブジェクトは更新されます (コード リスト 14-1 およびコード リスト 14-2 の手順 4 を参照)。確認応答モード、トランザクション モードなどのセッション ステートは、更新が発生するたびに保持されます。更新後も createMessageProducer() などの呼び出しに対して同じセッション オブジェクトを使用できます。
以下では、Session が再接続されるときに発生する可能性のある特殊なケースについて説明します。
javax.jms.TransactionRolledBackException を送出して失敗します。JMS Session のトランザクションがネットワークの更新にまたがっている場合、そのトランザクションのコミットは (アプリケーション コードから見て) 更新の前にトランザクションの一部として実行された処理を保証できません。
Session 更新後の send() や receive() などの処理では例外は送出されません。例外が送出されるのは更新後の最初のコミットだけです。ただし、ネットワークの切断時に JMS Session に保留中のトランザクション処理がなかった場合は、Session 更新後の最初のコミットでも例外は送出されません。Session.commit() で例外が送出されると、クライアント アプリケーション コードでは再度同じ (暗黙的に更新された) JMS オブジェクトを使用するトランザクションですべての処理を単純に再試行できます。更新前の古くなった処理は、コミットも複製もされません。
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 を参照)。
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 には、以下のコンフィグレーション パラメータが含まれています。これらのパラメータを使用して、コンシューマの再接続機能の動作を制御できます。
Administration Console を使用して接続ファクトリのクライアント パラメータをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「接続ファクトリのクライアント パラメータのコンフィグレーション」を参照してください。これらのパラメータの詳細については、『WebLogic Server MBean リファレンス』の「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 の「ハートビート」通知を待機する必要があります。詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「クラスタのフェイルオーバとレプリケーション」を参照してください。 |
| 注意 : | WebLogic JMS では、分散トピックでの恒久サブスクリプションはサポートされていません。したがって、更新時の別の分散トピック メンバーへのフェイルオーバは問題にはなりません。 |
コンシューマがトピックの非恒久サブスクライバである場合、アプリケーションからは更新後も問題なく消費が行われているように見えても、トピックにパブリッシュされたメッセージが、コンシューマの不足などが原因で再接続中に破棄されている可能性があります。このようなメッセージの破棄は、同期非恒久サブスクライバでも非同期恒久サブスクライバでも発生します。
コンシューマの更新機能の性質上、クライアント アプリケーション コードから明示的に回復を呼び出さなくても、メッセージの再配信が発生する可能性があります。これは、コンシューマを更新すると、暗黙的に回復と同等の効果が生じるためです。これが、暗黙的なコンシューマの更新がデフォルトで有効になっていない主な理由です。なお、この場合でも、問題なく確認応答されたメッセージが再配信されることはありません。
また、これも稀なケースですが、分散トピックの非恒久サブスクライバが、再配信とマークされていない重複メッセージを受信することもあります (たとえば、トピック内でメッセージが破棄されるより前にフェイルオーバが発生した場合)。これは、更新の前後で特定のトピック メンバーに固定されていない分散トピックの非恒久サブスクライバを更新した結果として発生します。
確認応答モードの違いが原因で、コンシューマの再接続動作に差異が生じることはありません。ただし、すでに説明したように、AUTO_ACK 以外の確認応答モードでは、サービスの品質が低下した可能性があることをアプリケーションに通知するため、更新後の最初の確認応答呼び出しで LostServerException が送出されます。
JMS サーバをクラスタ内の別のサーバに移行した場合、コンシューマが必ず再接続されるとは限りません。コンシューマが送り先と一緒に移行されていない場合は、例外が送出されるか、コンシューマが有効でなくなったことをアプリケーションに通知する onException が発生します。回避策としては、アプリケーションで例外ハンドラまたは onException を使用してコンシューマを更新します。
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 接続ファクトリの [再接続ポリシー] を無効にします。
[再接続ポリシー] フィールドの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : クライアント」を参照してください。
その他の JMS 接続ファクトリ クライアント パラメータの詳細については、『WebLogic Server MBean リファレンス』の「ClientParamsBean」を参照してください。
以下の JMS オブジェクトの暗黙的なフェイルオーバは、WebLogic Server 9.2 ではサポートされていません。
javax.jms.QueueBrowser)。 javax.jms.TemporaryQueue および javax.jms.TemporaryTopic)。 | ヒント : | サーバやネットワークに障害が発生した後でも、一時的な送り先にアクセスできることがあります。これは、サーバのロード バランシングの結果として、一時的な送り先が常にローカル接続ファクトリと同じサーバ インスタンスにあるとは限らないためです。したがって、サーバやネットワークに障害が発生した後も一時的な送り先にアクセスでき、プロデューサからのメッセージが引き続き送信されている場合、自動的に再接続されたコンシューマが、障害前に接続されていたのと同じ一時送り先からのメッセージを消費できるかどうかは分かりません。 |
BEA では、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 Server のコアに実装される移行フレームワークを使用します。これにより、WebLogic JMS は移行リクエストに正しく応答できるようになり、WebLogic JMS サーバのオンラインとオフラインの切り替えが順序立って行われるようになります。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への応答としての移行も含まれます。
いったん適切にコンフィグレーションすると、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server へ移行できます。
新しくサーバを起動し、表 14-3 のタスクのうち 1 つ以上を実行することで、障害が発生した WebLogic Server から JMS データを回復できます。
| 注意 : | クラッシュした、または管理サーバからアクセスできないサーバ インスタンスからサービスを移行する場合は、特別な考慮事項があります。移行を実行する時点で、以前アクティブだったサービスのホストに管理サーバからアクセスできない場合は、『WebLogic Server クラスタ ユーザーズ ガイド』の「現在アクティブなホストがない場合の移行」を参照してください。 |
| 注意 : | JMS 永続ストアに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストアに格納されているメッセージ数に比例するよう増加させてから、再起動してください。 |
新しく WebLogic Server を起動する方法の詳細については、「サーバの起動と停止 : クイック リファレンス」を参照してください。障害が発生したサーバの回復については、『サーバの起動と停止の管理』の「サーバ障害の回避とサーバ障害からの回復」を参照してください。
移行可能サービスの定義の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「サービスの移行」を参照してください。
  
|
