| Oracle® Fusion Middleware Oracle Service Busの管理 12c (12.1.3) E53003-05 |
|
 前 |
 次 |
この章では、実行中のパイプラインのリシーケンス・グループをモニターする方法と、メッセージのリシーケンス中および処理中に発生したエラーからの回復方法について説明します。
この章の内容は次のとおりです。
Service Busパイプラインは、リシーケンサを使用して、ランダムな順序で到着するメッセージを、選択したリシーケンス方針に基づいて新しい順序に並べ替えるように構成できます。
リシーケンス方針には、ベスト・エフォート、標準およびFIFOがあります。メッセージは、そのメッセージのリシーケンス・グループIDとシーケンスIDに基づいてリシーケンスされます。これらのIDは、パイプライン構成で定義します。それぞれの方針でメッセージを順序付けする方法の詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』のリシーケンサの概要に関する項および順序のリシーケンスに関する項を参照してください。
Fusion Middleware ControlのService Busホーム・ページにある「リシーケンス・メッセージ」タブにはリシーケンス情報が表示されるため、リシーケンス・グループのヘルスをモニターできます。このページには、メッセージとグループのステータスが、各メッセージとグループに関連付けられたService Busのパイプラインおよびプロジェクトとともに示されます。このページからは、タイムアウトになったグループのロック解除、失敗したメッセージの再送信、グループの処理をブロックしているメッセージのスキップを実行できます。
ヘルスの統計は、リシーケンサには公開されません。そのかわりに、関連するサービス・コンポーネント(パイプライン・サービスやプロキシ・サービスなど)の統計をモニターできます。
「リシーケンス・メッセージ」ページには、リシーケンス・グループおよびメッセージのメッセージ処理に関する実行ステータスが表示されます。リシーケンス・メッセージは、次のいずれかの状態になります。
実行中
フォルト
完了
中止
グループが実行中状態のときには、すべてのメッセージが正常に処理されています。完了状態の場合は、すべての利用可能なメッセージの処理を完了しています。リシーケンス・グループは、リシーケンス・エラー、メッセージ・エラー、データベース・エラー、またはグループ・タイムアウトのためにフォルト状態になることがあります。「完了メッセージのパージ」グローバル設定が選択されていない場合、完了メッセージのみが結果に表示されます。それ以外の場合、完了メッセージはデータベースからパージされ、このページに表示できません。
フォルトやタイムアウトが原因で、リシーケンス・グループにおけるメッセージ処理が中断されたときには、中断されたグループに関する追加情報を確認して、メッセージ処理の再開方法を指定できます。フォルトのタイプによっては、メッセージの処理をキャンセルすることも、ペイロードを変更してメッセージを再処理することもできます。グループがタイムアウトになったときには、その次に利用可能なインスタンスにスキップして処理を再開できます。
リシーケンス・エラーは、メッセージ永続性またはメッセージ実行の進行中に発生することがあります。永続性エラーには、グループIDまたはシーケンスIDの評価時に発生するものや、ペイロードおよびメッセージ・コンテキストの変数を永続化するときに発生するものがあります。実行エラーには、データベースへのアクセス時に発生するものや、パイプラインに送信されたときのメッセージの処理時に発生するものがあります。グループのタイムアウトは、到着しないメッセージをグループが予期して待機しているときに、標準リシーケンサで発生することがあります。
リシーケンサのメッセージ処理はデータベースに依存します。データベース表は、Service Busメインの作成時にリポジトリ作成ユーティリティ(RCU)を実行すると自動的に作成されます。メッセージは、リシーケンサのグローバル設定でデータベースからパージするように構成したときにのみ、データベースからパージされます。メッセージおよびメッセージのメタデータをパージする方法の詳細は、「完了リシーケンサ・メッセージの自動パージ」を参照してください。
Service Busには、データベース内のリシーケンサの表をパージおよび管理するためのスクリプトが用意されています。詳細は、「リシーケンサ表の管理」を参照してください。
リシーケンサはアクティブ化した後で変更を加えると、実行時のメッセージ処理方法に影響を与えます。リシーケンサに影響するアクティビティとして、リシーケンサ構成の更新、リシーケンサの削除、またはリシーケンサに関連付けられたパイプラインの名前変更や移動があげられます。通常の処理時、リシーケンサはメッセージをデータベースに格納し、メッセージの並べ替えが完了すると、メッセージは別のスレッドで実行されます。メッセージの処理中にパイプラインからリシーケンサを削除すると、次の事項が発生します。
データベースから処理のために取り出されていないメッセージは、データベースに維持されます。自動的にクリーンアップされることはありません。
その時点で処理のためにデータベースから取り出されている(ただし、パイプラインには送信されていない)メッセージは、リシーケンサがアンデプロイされたことを示すエラー・メッセージを生成します。これらのメッセージもデータベースに維持されます。
その時点でパイプラインで処理されているメッセージは、それまでのリシーケンサ構成を使用して実行されます。
リシーケンサに関連付けられたパイプラインを名前変更または移動すると、そのリシーケンサは停止し、新しいリシーケンサ・インスタンスが新しいパスを使用して作成されます。変更が行われた時点でメッセージの処理が完了している場合は、前述したようにメッセージが処理されます。
メッセージの処理中にリシーケンサ構成を更新すると、メッセージが処理されなくなる可能性があります。たとえば、グループIDを変更すると、元のグループIDでデータベースに格納されているメッセージは処理のために取り出されなくなり、手動で消去するまでデータベースに維持されます。
リシーケンサは、サーバーがシャットダウンされたときに、メッセージがプロセスのどの段階にあるかによって異なる方法でメッセージを処理します。ここでは、異なる3つのケースについて説明します。
メッセージ永続性のために、リシーケンサは、その時点でトランザクションが存在する場合はそのトランザクションに加わります。トランザクションが存在しない場合は、リシーケンサが独自のトランザクションを開始します。プロキシ・サービスがトランザクションの場合、そのトランザクションはロールバックされ、メッセージはインバウンド・サービスのトランザクション設定に基づいて再配信されます。プロキシ・サービスがトランザクションでない場合は、メッセージが失われることがあります。これは、サーバーがシャットダウンされる前に、リシーケンサのトランザクションがコミットできたかどうかによって決まります。
ロッカーがグループにロック済のマークを付けていて、そのグループのメッセージを処理する予定のサーバーがシャットダウンされると、リシーケンサは、このグループを処理するために別の管理対象サーバーに移動することを試行します。
リシーケンサを使用するサービスでは、実行時にリシーケンサがメッセージを処理する方法を制御するグローバル設定を構成できます。Service Busには、これらのリシーケンサの操作設定が用意されています。
これらは、グローバル設定専用であり、サービス・レベルでは適用できません。
リシーケンサ・ロッカーのスレッドのスリープ: ロッカー・スレッドのスリープ間隔(秒単位)。処理できるメッセージを持つグループをリシーケンサが見つけられないときに、ロッカー・スレッドは指定した期間スリープ状態になります。処理可能なメッセージを持つグループが見つかった場合は、データベース・シークの各繰返しの間でロッカー・スレッドがスリープ状態になることはありません。
リシーケンサ最大ロック済グループ数: データベース・シークの1回の繰り返しで処理のために取得できるリシーケンサ・グループの最大数。取得されたグループは、処理用のワーカー・スレッドに割り当てられます。
完了メッセージのパージ: このオプションを選択すると、Service Busは、処理が完了しているリシーケンス済メッセージをリシーケンサ・データベースからパージします。
グローバル設定の構成の詳細は、「操作設定の表示と構成」を参照してください。
注意:
リシーケンスに成功したインスタンスと失敗したインスタンスをモニターする場合は、パイプラインの実行トレースも有効にしてください。
リシーケンス済メッセージは、Service Busホーム・ページから「リシーケンス・メッセージ」タブでモニターできます。
「リシーケンス・メッセージ」ページでは、モニターする特定のグループやコンポーネントを検索して、その結果にメッセージの状態によるフィルタを適用できます。このページを使用して、メッセージの失敗があったかどうか、またはすべてのグループがメッセージを正常に処理しているかを確認します。
リシーケンス済メッセージについてモニターできる情報には、グループおよびメッセージID、メッセージとそれが属するプロジェクトを処理するサービス、現在のメッセージ・ステータス、およびWSDL操作がある場合はその名前が含まれます。次の図は「リシーケンス・メッセージ」ページを示しています。
リシーケンス・グループおよびメッセージをモニターするには:
「リシーケンス・メッセージ」表でグループIDをクリックすると、「リシーケンス・グループ」ダイアログが開きます。このダイアログには、そのグループがメッセージを正常に処理しているかどうかを示すメッセージが表示されます。「リシーケンス・グループ」ダイアログには、グループに関して次に示す情報が示されます。また、示される情報はグループの状態に応じて異なります。
グループがタイムアウト状態またはフォルト状態であるかどうか
グループ内のブロッキング・メッセージ(存在する場合)
グループのロック解除後に処理される後続のメッセージ
グループ内のメッセージ処理の停止後の時間
グループのロック解除のための指示テキスト
リシーケンス・グループに関する情報を表示するには:
リシーケンス・グループにメッセージ・エラー、データベース・エラー、またはタイムアウトが発生したときに、Service Busには、その問題から回復する(場合によっては、問題を修正する)手段が用意されています。
グループ内でスタック状態になっていて、追加のメッセージの処理をブロックしているメッセージはスキップできます。また、フォルトが発生したメッセージのペイロードを変更して、そのメッセージの再処理を試行することもできます。次からの各項では、リシーケンスの問題を修正する方法と、その問題から回復する方法について説明します。
標準リシーケンサ・グループの場合は、「リシーケンス・グループ」ダイアログに、次順のシーケンスIDをスキップして、シーケンス内の後続メッセージの処理を再開するオプションが提供されます。これは、グループが実行中であっても、到着することのないメッセージを待機している可能性がある場合に役立ちます。標準リシーケンサは、それぞれのグループに正しいシーケンスを生成できるようになるまで、メッセージをデータベースに保留します。特定のグループの次順のシーケンスIDを持つメッセージがいつまでも到着しない場合、そのグループの保留中のメッセージは、グループのロックを手動で解除して後続メッセージにスキップするまで保留され続けます。
注意:
シーケンスIDを手動でスキップした後で、そのIDを持つ欠落メッセージが到着したときには、そのメッセージを処理する必要がある場合、Fusion Middleware Controlでそのメッセージを手動で実行する必要があります。このメッセージは、自動的には回復されません。
リシーケンス・グループ内のメッセージをスキップするには:
グループは、予期されるメッセージの待機中にグループの処理が停止するとタイムアウト状態になり、グループ内の残りのメッセージをブロックするようになります。次順のシーケンスIDにスキップすると、グループのブロックを解除できます。タイムアウトになったグループには、次の情報が表示されます。
最後に処理したメッセージのシーケンスID
次に処理されるメッセージのシーケンスIDと、そのメッセージのインスタンスID
注意:
シーケンスIDを手動でスキップした後で、そのIDを持つ欠落メッセージがタイムアウト後に到着したときには、Fusion Middleware Controlでそのメッセージを手動で実行する必要があります。これは、自動的には回復されません。
グループのタイムアウトから回復するには:
「リシーケンス・グループ」ダイアログが表示されます(図6-2を参照)。
グループは、グループ内のいずれかのメッセージが処理中にエラーをスローしたときに、フォルト状態になります。フォルトが発生したときには、メッセージを修正して再試行することも、メッセージの処理をキャンセルすることもできます。フォルトのあるリシーケンス・グループについては、フォルトが発生したグループの「リシーケンス・グループ」ダイアログに、次の情報が示されます。
最後にメッセージが処理された時間
フォルトが発生したメッセージのシーケンスID
次に処理されるメッセージのシーケンスIDと、そのメッセージのインスタンスID
ペイロード
リシーケンスのフォルトから回復するには:
「リシーケンス・グループ」ダイアログが表示されます(図6-3を参照)。
