| Oracle® Fusion Middleware Oracle WebLogic Serverサーバー環境の管理 12.1.3 12c (12.1.3) E56250-07 |
|
 前 |
 次 |
この章では、WebLogic Server 12.1.3で、アプリケーションがワーク・マネージャを使用してその作業に優先順位を付ける仕組みを構成する方法について説明します。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク・マネージャを定義し、これをWebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用します。
この章には次の項が含まれます:
以前のバージョンのWebLogic Serverでは、複数の実行キューで処理を実行していました。異なるクラスの作業は、優先度や順序の要件に基づいて、また、デッドロックを回避するために、別々のキューで実行されていました。デフォルトの実行キュー(weblogic.kernel.default)に加え、内部管理トラフィック専用にあらかじめ構成されたキュー(weblogic.admin.HTTP、weblogic.admin.RMIなど)がありました。
ユーザーは、デフォルト・キューのスレッドの数を変更することでスレッドの使用状況を制御したり、特定のアプリケーションが全体のシステム負荷に関係なく一定数のスレッドにアクセスできるようカスタム実行キューを構成したりできました。
このバージョンのWebLogic Serverでは、1つのスレッド・プールですべてのタイプの作業を実行するようになりました。作業の優先順位は、ユーザーが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際にリクエストを実行するのにかかった時間、リクエストをプールに出し入れする割合、などがあります。
共通スレッド・プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニターし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。この新しい戦略により、管理者は、カスタムの実行キューを構成、モニター、チューニングする際の手間や複雑さを避けて、より簡単に処理リソースを割り当てたり、パフォーマンスを管理したりできるようになりました。
WebLogic Serverでは、管理者が定義したパラメータと実行時の実際のパフォーマンスおよびスループットを考慮にいれた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。
管理者は、一連のスケジューリング・ガイドラインを構成し、それらを1つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション・コンポーネントに関連付けたりできます。たとえば、スケジューリング・ガイドラインのセットを1つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っているリクエストが実行スレッドに割り当てられます。
|
注意: すべてのワーク・マネージャからの作業リクエストは、1つのスレッド・プールによって実行されます。それぞれのワーク・マネージャに対して別々のスレッド・プールは作成されません。 |
アプリケーション内の作業を管理するには、以下のうち1つまたは複数のワーク・マネージャ・コンポーネントを定義します。
フェア・シェアリクエスト・クラス
レスポンス時間リクエスト・クラス
最小スレッド数制約
最大スレッド数制約
容量制約
コンテキストリクエスト・クラス
これらのコンポーネントの詳細は、「リクエスト・クラス」または「制約」を参照してください。
これらのワーク・マネージャ・コンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらのすべてのコンポーネント(コンテキスト・リクエスト・クラス以外。「例2-3」を参照)をカプセル化したワーク・マネージャを定義し、このワーク・マネージャの名前をアプリケーションのデプロイメント記述子で参照することもできます。複数のワーク・マネージャを定義することも可能です。ワーク・マネージャの適正数は、WebLogic Serverでホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。
ワーク・マネージャは、次のいずれかの構成ファイルまたはWebLogic Server管理コンソールを使用して、ドメイン・レベル、アプリケーション・レベル、およびモジュール・レベルで構成できます。
config.xml - config.xmlで指定したワーク・マネージャは、ドメイン内の任意のアプリケーションまたはアプリケーション・コンポーネントに割り当てることができます。
weblogic-application.xml - アプリケーション・レベルで指定したワーク・マネージャは、そのアプリケーション、またはそのアプリケーションのコンポーネントに割り当てることができます。
weblogic-ejb-jar.xmlまたはweblogic.xml - コンポーネント・レベルで指定したワーク・マネージャは、そのコンポーネントに割り当てることができます。
weblogic.xml - Webアプリケーション用に指定したワーク・マネージャ。
例 2-1に、ワーク・マネージャの定義の例を示します。
例 2-1ワーク・マネージャ・スタンザ
<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</min-threads-constraint>
</work-manager>
例2-1のワーク・マネージャを割り当てて、Webアプリケーション全体のディスパッチ・ポリシーを制御するには、例2-2のコードをWebアプリケーションのweblogic.xmlファイルに追加します。
例 2-2 Webアプリケーションでのワーク・マネージャの参照
<wl-dispatch-policy>highpriority-workmanager</wl-dispatch-policy>
ワーク・マネージャを割り当てて、特定のサーブレットのディスパッチ・ポリシーを制御するには、次のコードをWebアプリケーションのweb.xmlファイルに追加します。
<servlet>
...
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>highpriority_workmanager</param-value>
</init-param>
...
</servlet>
ワーク・マネージャで定義および使用できるコンポーネントについては次の項で説明します。
リクエスト・クラスは、リクエストへのスレッドの割当てに使用するスケジューリング・ガイドラインを表現します。リクエスト・クラスを使用すると、優先度の高い作業が優先度の低い作業より後に送信された場合でも、優先度の高い作業を優先度の低い作業より前にスケジューリングすることができます。WebLogic Serverでは、各モジュールがリクエストを完了するのにかかる時間が考慮されます。
リクエスト・クラスはベスト・エフォートを定義します。リクエスト・クラスは、構成された割合の一貫性が維持されることを保証しません。観測された割合は、十分な要求の期間中に次のようないくつかの要素によって変化する場合があります。
特定の時点におけるキュー内にある様々なリクエスト・クラスからのリクエストの混在。たとえば、ワーク・マネージャ・キューで優先度の高いリクエスト・クラスから十分なリクエストがない場合、構成された割合よりも多い数のリクエストが優先度の低いリクエスト・クラス用に処理される可能性があります。
割合はスレッドの使用時間によって指定されるため、数が少なく、時間のかかるリクエストと同じスレッド使用時間で、時間のかからないリクエストの方が多く処理される可能性があります。
リクエスト・クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング・ガイドラインを表現します。1つのワーク・マネージャに、リクエスト・クラスを1つだけ指定することもできます。
fair-share-request-class: リクエストの処理に必要な平均スレッド使用時間を指定します。デフォルトのフェア・シェア値は50です。
たとえば、WebLogic Serverで2つのモジュールを実行しているとします。ModuleAのワーク・マネージャではfair-share-request-classが80に設定されており、ModuleBのワーク・マネージャではfair-share-request-classが20に設定されています。
各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッドの数を超えている状態)が続く間は、スレッド使用時間の80%がModuleAに、20%がModuleBに割り当てられます。
|
注意: フェア・シェア・リクエスト・クラスの値は、割合ではなく相対値で指定します。したがって、上の例でリクエスト・クラスを400と100に設定しても相対値としては同じです。 |
response-time-request-class - レスポンス時間の目標値をミリ秒単位で指定します。レスポンス時間の目標値は、個々のリクエストには適用されません。かわりに、そのクラスのリクエストの許容可能な待機時間を、レスポンス時間の目標値から観察された平均スレッド使用時間を減算することで算出し、そのクラスのリクエストの平均的な待機が許容可能な待機時間に比例するようにリクエストをスケジューリングします。
たとえば、前の例のようにModuleAとModuleBがあり、レスポンス時間の目標値がそれぞれ2000ミリ秒と5000ミリ秒に設定されており、個々のリクエストの実際のスレッド使用時間がレスポンス時間の目標値よりも短いとします。レスポンスとリクエストの間に「思考時間」による遅延がないとすると、各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッドの数を超えている状態)が続く間は、ModuleAとModuleBに対するリクエストは平均レスポンス時間が2対5の割合になるようにスケジューリングされます。ModuleAとModuleBの実際の平均レスポンス時間はレスポンス時間の目標値より長くなったり短くなったりしますが、設定されている目標値の常分数または倍数になります。たとえば、ModuleAのリクエストの平均レスポンス時間が1,000ミリ秒である場合、ModuleBのリクエストの平均レスポンス時間は2,500ミリ秒になります。
前の項では、同じリクエスト・クラスを使用して別の作業にスケジューリングを関連付けることで、フェア・シェアとレスポンス時間に基づいたリクエスト・クラスについて説明しました。フェア・シェアとレスポンス時間リクエスト・クラスを併用すると、レスポンス時間スケジューリングに著しく偏ったスケジューリングになります。
context-request-class - コンテキスト情報(現在のユーザー、現在のユーザーのグループなど)に基づいてリクエスト・クラスをリクエストに割り当てます。
たとえば、例2-3のcontext-request-classでは、リクエストのsubjectおよびroleプロパティの値に基づいてリクエスト・クラスがリクエストに割り当てられます。
例 2-3コンテキストリクエスト・クラス
<work-manager>
<name>context_workmanager</name>
<context-request-class>
<name>test_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>
</work-manager>
例2-3のcontext_workmanagerによって参照されるhigh_fairshareリクエスト・クラスとlow_fairshareリクエスト・クラスは、config.xmlで次のように定義できます。
<self-tuning>
...
<fair-share-request-class>
<name>high_fairshare</name>
<target>myserver</target>
<fair-share>75</fair-share>
</fair-share-request-class>
<fair-share-request-class>
<name>low_fairshare</name>
<target>myserver</target>
<fair-share>25</fair-share>
</fair-share-request-class>
...
</self-tuning>
|
注意: Webアプリケーションのワーク・マネージャがコンテキスト・リクエスト・クラスを参照している場合、最初のユーザー呼出しはデフォルトのリクエスト・クラスを通じて実行され、同じセッションの以降の呼出しはユーザー定義のリクエスト・クラスを通じて実行されます。コンテキスト・リクエスト・クラスを使用するとき、セッション・タイムアウト値を設定すると、ワーク・マネージャ・キューでリクエストが待機中にセッションの期限が切れなくなります。 |
制約を使用すると、リクエストを実行するために割り当てられるスレッドの最小数と最大数、およびWebLogic Serverがリクエストを拒否し始めるまでにキューに入れたり実行したりできるリクエストの総数を定義できます。
以下のタイプの制約を定義できます。
max-threads-constraint - 制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、統合された3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。
max-threads-constraintは、リクエストが依存するリソース(たとえば接続プール)の可用性の観点から定義できます。
max-threads-constraintは、リクエスト・クラスによるスレッドのフェア・シェアの実現やレスポンス時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行の数が制限値を下回るまで、このタイプのリクエストはスケジューリングされません。制限値を下回ると、フェア・シェアまたはレスポンス時間の目標値に基づいて作業がスケジューリングされます。
min-threads-constraint - 制約対象のリクエストに割り当てられるスレッドの数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraintの値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に便利です。
min-threads-constraintによってフェア・シェアが向上するとは限りません。このタイプの制約は、主にサーバー・インスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス・クラス内のリクエストがフェア・シェアを超えていた場合でも、この制約によってリクエストがスケジューリングされます。
capacity - サーバーは容量に達したときにのみリクエストを拒否します。デフォルトは-1です。容量には、制約対象の作業セットからの全リクエスト(キューにあるリクエストと実行中のリクエスト)が含まれます。個々の容量しきい値を超えた場合、またはグローバル容量を超えた場合に作業が拒否されます。この制約は、グローバル・キューのしきい値とは無関係です。
リクエストがWebLogic Server管理者グループに属するユーザーによって行われる場合、capacity制約は適用されません。
スタック・スレッドに応じて、スタック・スレッド・ワーク・マネージャ・コンポーネントを定義できます。このコンポーネントを使用すると、ワーク・マネージャを停止したり、アプリケーションを管理モードにしたり、サーバー・インスタンスを障害が発生したものとしてマークしたりできます。
たとえば、例 2-4で定義するワーク・マネージャは、2つのスレッドが30秒を超えてスタックすると停止します。
WebLogic Serverは、自己チューニング・スレッド・プール用に3つのスレッド・グループを管理します。
実行スレッド: ワーク・マネージャに送信された作業リクエストを現在実行しているスレッド
アイドル・スレッド: 作業リクエストをアイドル状態で待機しているスレッド
アイドル・スレッドには、前の作業リクエストを完了し、新しいリクエストを待っているスレッドおよび将来の作業負荷を予想するために使用量統計情報に基づいて自己チューニング・スレッド・プールによって作成されるスレッドが含まれます。
スタンバイ・スレッド: 現在作業リクエストを処理していないまたは作業リクエスト待ちではないスレッド
スタンバイ・スレッドは、自己チューニング・スレッド・プールのスレッド数にカウントされません。自己チューニング・スレッド・プールが使用量統計情報に基づいてスレッド数を減らすことを決定すると、スレッドはアイドル・スレッドのグループからスタンバイ・スレッドのグループに移動します。逆に、自己チューニング・スレッド・プールがスレッド数を増やすことを決定すると、まずスタンバイ・スレッド・グループでスレッドを探し、アイドル・スレッド・グループに移動しようとします。自己チューニング・スレッド・プールは、スタンバイ・グループに十分なスレッドがない場合のみ新しいスレッドを作成します。
スタンバイ・スレッド数が内部の最大制限値の256に達するとスレッドはシャットダウンします。作業負荷が大きいときにWebLogic Serverインスタンスが新しいスレッドの作成を回避できるように、WebLogic Serverが自己チューニング・スレッド・プール数を増やす必要がある場合に多数のスタンバイ・スレッドが準備されていることが理想です。スタンバイ・スレッドは、最小スレッド制約を満たすためにも作成して使用できます。詳細は、「制約」を参照してください。
デフォルトでは、自己チューニング・スレッド・プール・サイズの制限は400です。この制限には、すべての実行スレッドおよびアイドル・スレッドが含まれますが、スタンバイ・スレッドは含まれません。KernelMBeanのSelfTuningThreadPoolSizeMax属性を使用してこの制限値を構成できます。自己チューニング・スレッド・プールがスレッド数の上限値に達したときでも、システムが追加の作業負荷をサポートできる場合、サイズの制限値を上げることができます。逆に、CPUなどのシステム・リソースが少ないスレッド数で過負荷になる場合、制限値を下げることができます。ただし、SelfTuningThreadPoolSizeMaxの制限値を下げる場合、設定値が低すぎるとシステムの作業負荷を処理するために十分なスレッドを自己チューニング・スレッド・プールが作成できなくなる場合があることに注意してください。この結果、一部のワーク・マネージャで保留中の作業リクエストのバックログが発生する可能性があります。
|
注意: 最小スレッド制約は、特にWebLogic Serverインスタンスの負荷が大きい場合にワーク・マネージャの作業リクエストを実行しているスレッド数に影響する可能性があります。 |
自己チューニング・スレッド・プールは、割り当てられた最小スレッド制約を満たすために新しいスタンバイ・スレッドを作成してワーク・マネージャの受信作業リクエストを処理する際にSelfTuningThreadPoolSizeMax属性を考慮しません。これは、サーバー間のデッドロックを回避するために使用するように設計されている最小スレッド制約を使用してワーク・マネージャの作業リクエストを処理するためにスレッドを割り当てることが重要であるためです。
この結果、構成した数のスレッドが構成したすべての最小スレッド制約に割り当てられる最悪シナリオを考慮すると、自己チューニング・スレッド・プールによって維持されるスレッドの最大可能数は、構成したSelfTuningThreadPoolSizeMax属性値の合計とWebLogic Serverインスタンスで構成されたすべての最小スレッド制約値の合計です。
基本的に、ワーク・マネージャには3つのタイプがあります。各タイプは、スコープおよび定義と使用のされ方によって特徴付けられます。
スレッド管理を処理し、自動チューニングを実行するため、WebLogic Serverではデフォルトのワーク・マネージャが実装されています。このワーク・マネージャは、アプリケーションのデプロイメント記述子で他のワーク・マネージャが指定されていない場合に、アプリケーションによって使用されます。
多くの場合、デフォルトのワーク・マネージャはほとんどのアプリケーション要件を十分に満たしていると考えられます。WebLogic Serverのスレッド処理アルゴリズムは、デフォルトで各アプリケーションに、フェア・シェアを割り当てます。各アプリケーションは、スレッドに対して同等の優先度を与えられており、スレッドを独占できないようになっています。
サーバーにデプロイされているすべてのアプリケーションおよびモジュールで使用できるグローバル・ワーク・マネージャを、WebLogic Server管理コンソールまたはconfig.xmlで作成できます。
アプリケーションは、グローバルに定義されたワーク・マネージャをテンプレートとして使用します。各アプリケーションは、そのアプリケーションと関連付けられた作業を処理する、自身のインスタンスを作成し、その作業を他のアプリケーションから分離します。そうすることで、同じディスパッチ・ポリシーを使用している2つのアプリケーションに向かうトラフィックを処理できます。各アプリケーションの作業を別個に処理することで、別のアプリケーションのスレッド管理に影響を及ぼすことなく、アプリケーションを停止できます。各アプリケーションには、専用のワーク・マネージャ・インスタンスが実装されていますが、基底となるコンポーネントは共有されます。
グローバル・スコープのワーク・マネージャに加えて、特定のアプリケーションまたはモジュールのみで使用できるワーク・マネージャも作成できます。アプリケーション・スコープのワーク・マネージャは、WebLogic Server管理コンソールと次の記述子で定義できます。
weblogic-application.xml
weblogic-ejb-jar.xml
weblogic.xml
ワーク・マネージャが明示的に割り当てられていないアプリケーションでは、デフォルトのワーク・マネージャが使用されます。
ワーク・マネージャにメソッドを割り当てるには、デプロイメント記述子で<dispatch-policy>要素を使用します。後方互換性を維持するため、<dispatch-policy>でカスタム実行キューも指定できるようになっています。例については、例 2-2を参照してください。
ワーク・マネージャ、リクエスト・クラス、および制約では、以下が必要になります。
定義。ワーク・マネージャ、リクエスト・クラスおよび制約は、WebLogic Server管理コンソールを使用してドメインの構成内にグローバルに定義するか(WebLogic Server管理コンソールの「環境」>「ワーク・マネージャ」)、上に挙げたデプロイメント記述子のいずれかを使用して定義します。どちらの場合も、それぞれに名前を割り当てます。
マッピング。デプロイメント記述子で、ワーク・マネージャ、リクエストクラス、または制約のいずれかを、その名前を使用して参照します。
この項では、様々なデプロイメント記述子を使用したワーク・マネージャの定義例を示します。
必要に応じて、各デプロイメント記述子のスキーマも参照してください。
weblogic-ejb-jar.xml schema: http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.5/weblogic-ejb-jar.xsd
weblogic-application.xml schema: http://xmlns.oracle.com/weblogic/weblogic-application/1.6/weblogic-application.xsd
weblogic.xml schema - 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。
例2-5 ワーク・マネージャのエントリを含むweblogic-ejb-jar.xml
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar
http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.5/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>WorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name>
<dispatch-policy>weblogic.kernel.System</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>NonSystemWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name>
<dispatch-policy>workbean_workmanager</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>MinThreadsWorkEJB</ejb-name>
<jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name>
<dispatch-policy>MinThreadsCountFive</dispatch-policy>
</weblogic-enterprise-bean>
<work-manager>
<name>workbean_workmanager</name>
</work-manager>
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>30</max-stuck-thread-time>
<stuck-thread-count>2</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<name>MinThreadsCountFive</name>
<count>5</count>
</min-threads-constraint>
</work-manager>
<work-manager>
<name>lowpriority_workmanager</name>
<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>
</work-manager>
<work-manager>
<name>highpriority_workmanager</name>
<fair-share-request-class>
<name>high_priority</name>
<fair-share>100</fair-share>
</fair-share-request-class>
</work-manager>
<work-manager>
<name>veryhighpriority_workmanager</name>
<fair-share-request-class>
<name>veryhigh_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
</work-manager>
例2-6のEJBは、依存するリソース(接続プールおよびアプリケーション・スコープの接続プール)のインスタンスと同数のスレッドを取得するように構成されています。
例2-6 接続プール・ベースの最大スレッド数制約を含むweblogic-ejb-jar.xml
<weblogic-ejb-jar xmlns="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-ejb-jar
http://xmlns.oracle.com/weblogic/weblogic-ejb-jar/1.5/weblogic-ejb-jar.xsd">
<weblogic-enterprise-bean>
<ejb-name>ResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name>
<dispatch-policy>test_resource</dispatch-policy>
</weblogic-enterprise-bean>
<weblogic-enterprise-bean>
<ejb-name>AppScopedResourceConstraintEJB</ejb-name>
<jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB
</jndi-name>
<dispatch-policy>test_appscoped_resource</dispatch-policy>
</weblogic-enterprise-bean>
<work-manager>
<name>test_resource</name>
<max-threads-constraint>
<name>pool_constraint</name>
<pool-name>testPool</pool-name>
</max-threads-constraint>
</work-manager>
<work-manager>
<name>test_appscoped_resource</name>
<max-threads-constraint>
<name>appscoped_pool_constraint</name>
<pool-name>AppScopedDataSource</pool-name>
</max-threads-constraint>
</work-manager>
</weblogic-ejb-jar>
例2-7 CommonJワーク・マネージャを含むweblogic-ejb-jar.xml
CommonJの使い方については、「WebLogic ServerでのCommonJの使い方」およびCommonJのJavadocを参照してください。
例2-8 weblogic-application.xml
<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-application
http://xmlns.oracle.com/weblogic/weblogic-application/1.6/weblogic-application.xsd">
<max-threads-constraint>
<name>j2ee_maxthreads</name>
<count>1</count>
</max-threads-constraint>
<min-threads-constraint>
<name>j2ee_minthreads</name>
count>1</count>
</min-threads-constraint>
<work-manager>
<name>J2EEScopedWorkManager</name>
</work-manager>
</weblogic-application>
例2-9のWebアプリケーションは、例2-8で定義したエンタープライズ・アプリケーションの一部としてデプロイされます。このWebアプリケーションの記述子では、2つのワーク・マネージャを定義しています。どちらのワーク・マネージャも、アプリケーションのweblogic-application.xmlファイルで定義した同じ最大スレッド数制約(j2ee_maxthreads)を参照しています。レスポンス時間のリクエスト・クラスは、ワーク・マネージャごとに異なっています。
例2-9 Webアプリケーション記述子
<weblogic xmlns="http://xmlns.oracle.com/weblogic"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic
http://xmlns.oracle.com/weblogic/1.0/weblogic.xsd">
<work-manager>
<name>fast_response_time</name>
<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>2000</goal-ms>
</response-time-request-class>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name>
</work-manager>
<work-manager>
<name>slow_response_time</name>
<max-threads-constraint-name>j2ee_maxthreads
</max-threads-constraint-name
<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>5000</goal-ms>
</response-time-request-class>
</work-manager>
</weblogic>
例2-10の記述子は、context-request-classを使用してワーク・マネージャを定義します。
例2-10 Webアプリケーション記述子
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app
http://xmlns.oracle.com/weblogic/weblogic-web-app/1.7/weblogic-web-app.xsd">
<work-manager>
<name>foo-servlet-1</name>
<request-class-name>test-fairshare2</request-class-name>
<max-threads-constraint>
<name>foo-mtc</name>
<pool-name>oraclePool</pool-name>
</max-threads-constraint>
</work-manager>
<work-manager>
<name>foo-servlet</name>
<context-request-class>
<name>test-context</name>
<context-case>
<user-name>anonymous</user-name>
<request-class-name>test-fairshare1</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
</context-request-class>
</work-manager>
</weblogic-web-app>
この項では、実行キューとの後方互換性を有効にし、実行キューのかわりにワーク・マネージャを使用するようアプリケーションを移行する方法について、説明します。
WebLogic Serverバージョン8.1では、スレッド管理の処理のために実行キューを実装していました。実行キューを使用すると、スレッド・プールを作成して、作業負荷の処理方法を決定できました。WebLogic Serverは、引続き後方互換性のために実行キューを提供しています。これは主に、アプリケーションの移行を支援するためです。ただし、新しいアプリケーションを開発する際には、ワーク・マネージャを利用して、より効率的にスレッド管理を行うことが必要です。
実行キューの有効化は、次のようにして行うことができます。
コマンド行オプション-Dweblogic.Use81StyleExecuteQueues=trueを使用する
config.xmlのカーネルMBeanを介してUse81StyleExecuteQueuesプロパティを設定
実行キューを有効にすると、すべてのワーク・マネージャの構成とスレッドの自動チューニングが無効になります。実行キューは、WebLogic Server 8.1で動作したときと同じように動作します。
有効化されたワーク・マネージャは、以下のルールに基づき、実行キューに変換されます。
ワーク・マネージャで最小スレッド数制約または最大スレッド数制約が実装されている場合、実行キューはワーク・マネージャと同じ名前で作成されます。実行キューのスレッド数は、制約で定義された値に基づいています。
ワーク・マネージャで制約が実装されていない場合、グローバル・デフォルト実行キューが使用されます。
ワーク・マネージャには、WorkManagerMBean構成MBeanを使用してアクセスすることができます。詳細は、「WorkManagerMBean」を参照してください。
WorkManagerMBeanへは、アプリケーションのワーク・マネージャへのアクセス方法に応じて、実行時ツリーまたは構成ツリーでアクセスします。
ワーク・マネージャがモジュール・レベルで定義されている場合、対応するComponentRuntimeMBeanを介して、WorkManagerRuntime MBeanが使用できます。
ワーク・マネージャがアプリケーション・レベルで定義されている場合、ApplicationRuntimeを介して、WorkManagerRuntimeが使用できます。
ワーク・マネージャがconfig.xml内でグローバルに定義されている場合、各アプリケーションは、専用のワーク・マネージャ・インスタンスを作成します。各アプリケーションには、アプリケーション・レベルで使用できる、専用の対応するWorkManagerRuntimeがあります。
WebLogic Serverワーク・マネージャでは、管理者がサーブレットおよびEJBに対してディスパッチ・ポリシーを設定できるよう、サーバー・レベルの構成を提供しています。
WebLogic Serverはまた、アプリケーション内からプログラム的に作業を処理するための方法も用意しています。これは、CommonJ APIを通じて提供されます。Weblogic Serverは、CommonJ仕様のcommonj.workパッケージおよびcommonj.timersパッケージを実装しています。
WebLogic ServerにおけるCommonJの実装に関する個別の情報は、「CommonJのJavadoc」を参照してください。
CommonJのWebLogic Server実装を使用すると、アプリケーションは、WebLogic Serverで構成済みの複数のワーク・マネージャを使用して、1つのリクエストのタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます。作業項目を同時に実行する必要のないアプリケーションでも、構成済みのワーク・マネージャを使用することができます。それには、デプロイメント記述子でワーク・マネージャを参照または作成するか、Java EEコネクタの場合はJCA APIを使用します。
WebLogic Server実装とCommonJ仕様の相違点をいくつか、以下に示します。
RemoteWorkItemインタフェースは、CommonJ仕様によって提供された任意指定のインタフェースであり、WebLogic Serverではサポートされていません。WebLogic Serverでは、独自のクラスタ・ロード・バランシングおよびフェイルオーバー・ポリシーを実装しています。作業負荷管理は、これらのポリシーに基づいて行われます。
WebLogic CommonJタイマーの動作は、java.util.Timerとは異なります。WebLogic CommonJタイマーは、実行が所定期間の2倍を超えると、それ以上の遅延を防止するため、いくらかの期間をスキップします。java.util.Timerは、このような処理を行いません。
WebLogic Server環境では、スレッドがスタック状態になった時にWorkListener.WorkRejectedメソッドが呼び出されます。
WebLogic Serverワーク・マネージャにアプリケーションからアクセスするにはディスパッチ・ポリシーを使用する必要がありますが、CommonJワーク・マネージャはアプリケーションから直接アクセスできます。次のサンプル・コードに、JNDIを使用してCommonJワーク・マネージャをルックアップする方法を示します。
InitialContext ic = new InitialContext();
commonj.work.WorkManager wm =
(commonj.work.WorkManager)ic.lookup("java:comp/env/wm/myWM");
CommonJワーク・マネージャの使い方の詳細は、CommonJのJavadocを参照してください。
外部定義したCommonJワーク・マネージャは、WebLogic Serverワーク・マネージャにマッピングできます。たとえば、次の例のように、記述子ejb-jar.xmlで定義したCommonJワーク・マネージャがあるとします。
<resource-ref> <res-ref-name>minthreads_workmanager</res-ref-name> <res-type>commonj.work.WorkManager</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref>
これをWebLogic Serverワーク・マネージャにリンクさせるには、WebLogic Serverの記述子(たとえばweblogic-ejb-jar.xml)のname要素を完全に一致させます。
<work-manager> <name>minthreads_workmanager</name> <min-threads-constraint> <count>5</count> </min-threads-constraint> </work-manager>
この手順は、web.xmlに定義したresource-refと同様です。WebLogic Serverワーク・マネージャは、モジュール記述子(たとえばweblogic-ejb-jar.xmlやweblogic.xml)またはアプリケーション記述子(weblogic-application.xml)で定義できます。
