この節では、以下の項目について説明します。
Oracle CEPでは、HTTPサーブレットと静的リソースをデプロイするJava WebサーバーとしてJetty(http://www.mortbay.org
/を参照してください)がサポートされています。
Oracle CEPでのJettyサポートは、バージョン1.2のOSGi HTTPサービスに基づいています。このAPIでは、実行時リソースと静的リソースにhttp://java.sun.com/products/servlet/docs.html
オブジェクトを動的に登録および登録解除する機能が提供されます。この仕様には、JavaサーブレットAPIバージョン2.1以上が必要です。
Oracle CEPでは、Jettyの以下の機能をサポートします。
Jettyの構成の詳細は、10.2項「Jettyサーバー・インスタンスの構成」を参照してください。
Oracle CEPでは、一般的な(同期)Javaサーブレットをサポートするだけでなく、非同期サーブレットもサポートします。非同期サーブレットはリクエストを受信し、スレッドを取得して作業を実行します。また、最終的には、アクションの完了を待機している間に(別のスレッドを再取得するよりも前に)スレッドを解放し、レスポンスを送信します。
Oracle CEPでは、ネットワークI/O (NetIO)を使用してJettyサービスのポートとリスニング・アドレスを構成します。
注意: Jettyは多重化されたネットワークI/Oに対応した組込み機能を備えています。ただし、同一ポート上での複数のプロトコルはサポートされません。 |
Oracle CEP Jettyサービスは、Oracle CEPワーク・マネージャを使用して、スケーラブルなスレッド・プーリングを可能にします。10.3項「Jetty構成の例」を参照してください。
注意: JettyにはJetty独自のスレッド・プール機能が用意されています。ただし、処理コストおよび構成の複雑さを最小限に抑えるために、Oracle CEPの自動チューニング・スレッド・プールを使用することをお薦めします。 |
Oracle CEPでは、アプリケーションがどのような優先順位で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメントが維持されます。ワーク・マネージャを定義して、アプリケーションに対してルールや制約を定義します。
この項では次の内容について説明します。
詳細は、10.2.3項「work-manager構成オブジェクト」を参照してください。
Oracle CEPでは、1つのスレッド・プールですべてのタイプの作業を実行します。作業の優先順位は、ユーザーが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際にリクエストを実行するのにかかった時間、リクエストをプールに出し入れする割合などがあります。
共通スレッド・プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニターし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。
Oracle CEPでは、定義済みのパラメータと実行時のパフォーマンスおよびスループットを考慮に入れた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。
ユーザーは、一連のスケジューリング・ガイドラインを構成し、それらを1つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション・コンポーネントに関連付けたりできます。たとえば、スケジューリング・ガイドラインのセットを1つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っているリクエストが実行スレッドに割り当てられます。
アプリケーション内の作業を管理するには、次のうち1つまたは複数のワーク・マネージャ・コンポーネントを定義します:
fairshare
: リクエストを処理するのに必要な平均スレッド使用時間を指定します。
たとえば、Oracle CEPで2つのモジュールを実行しているとします。ModuleA
のワーク・マネージャではfairshare
が80に指定されていて、ModuleB
のワーク・マネージャではfairshare
が20に指定されています。
各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッド数を超えている状態)が続く間は、スレッド使用時間の80%がModuleA
に、20%がModuleB
にそれぞれ割り当てられます。
注意: フェア・シェア・リクエスト・クラスの値は、割合ではなく相対値で指定します。したがって、上の例でリクエスト・クラスを400と100に設定しても相対値としては同じです。 |
max-threads-constraint
: この制約は、制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、組み合せた3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。
max-threads-constraint
は、リクエストが依存するリソース(たとえば接続プール)の可用性の観点から定義できます。
max-threads-constraint
は、リクエスト・クラスによるスレッドのフェア・シェアの実現やレスポンス時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行数が制限値を下回るまで、このタイプのリクエストはスケジューリングされません。制限値を下回ると、フェア・シェアまたはレスポンス時間の目標値に基づいて作業がスケジューリングされます。
min-threads-constraint
: この制約は、制約対象のリクエストに割り当てられるスレッド数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraint
の値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に便利です。
min-threads-constraint
によってフェア・シェアが向上するとはかぎりません。このタイプの制約は、主にOracle CEPインスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス・クラス内のリクエストがフェア・シェアを超えていた場合でも、この制約によってリクエストがスケジューリングされます。
Oracle CEPドメインを記述するconfig.xml
ファイル内にJetty HTTPサーバーのインスタンスを構成するには、次の構成オブジェクトを使用します。
jetty
: 詳細は、10.2.1項「jetty構成オブジェクト」を参照してください。
netio
: 詳細は、10.2.2項「netio構成オブジェクト」を参照してください。
work-manager
: 詳細は、10.2.3項「work-manager構成オブジェクト」を参照してください。
jetty-web-app
: 詳細は、10.2.4項「jetty-web-app構成オブジェクト」を参照してください。
Jettyに影響を与えるセキュリティ構成タスクの詳細は、9.8.1項「Jettyセキュリティの構成」を参照してください。
詳細は、次を参照してください:
次の表に示すパラメータを使用して、config.xml
ファイルにjetty
構成オブジェクトを定義します。
表10-1 jetty要素の構成パラメータ
パラメータ | タイプ | 説明 |
---|---|---|
network-io-name |
String |
使用するNetIOサービスの名前。NetIOサービスは、サーバーがリスニングするポートを定義します。 詳細は、10.2.2項「netio構成オブジェクト」を参照してください。 |
work-manager-name |
String |
スレッド・プール用に使用するワーク・マネージャの名前。指定しない場合はデフォルトのワーク・マネージャが使用されます。 詳細は、10.2.3項「work-manager構成オブジェクト」を参照してください。 |
scratch-directory |
String |
Webアプリケーション、JSPおよびその他のタイプのWebアーティファクトに必要な一時ファイルを保管するディレクトリの名前。 |
debug-enabled |
boolean |
JettyコードでOSGi Log Serviceを使用してデバッグ機能を有効にします。 |
name |
String |
jettyサーバー・インスタンスの名前。 |
次の表に示すパラメータを使用して、config.xml
ファイルにnetio
構成オブジェクトを定義します。
次の表に示すパラメータを使用して、config.xml
ファイルにwork-manager
構成オブジェクトを定義します。
次の構成オブジェクトを使用して、Jettyが使用するWebアプリケーションを定義します。
表10-4 jetty-web-app要素の構成パラメータ
パラメータ | タイプ | 説明 |
---|---|---|
context-path |
String |
このWebアプリケーションのデプロイ先となるWebサーバーのネームスペースのコンテキスト・パス。 設定しない場合、デフォルトで |
scratch-directory |
String |
JettyがこのWebアプリケーションの一時ファイルを保管する場所。 10.2項「Jettyサーバー・インスタンスの構成」の |
path |
String |
サーバー上のWebアプリケーションの場所を指すファイル名。ディレクトリまたはWARファイルを指定できます。 |
jetty-name |
String |
このWebアプリケーションのデプロイ先のJettyサービス名。既存の10.2項「Jettyサーバー・インスタンスの構成」の名前と一致している必要があります。 |
name |
String |
この構成オブジェクトの名前。 |
Oracle CEPでは、Jettyにデプロイするサーブレットの開発をサポートしています。標準のJava EE Webアプリケーションを作成し、10.2.4項「jetty-web-app構成オブジェクト」を使用してアプリケーションを構成します。
Oracle CEPでは、Java Servletバージョン2.4仕様に規定されているように、WARファイルまたは展開されたWARファイルのどちらでもパッケージのデプロイメントをサポートしています。
事前に構成されたWebアプリケーションをサーバーの構成に組み込むことによって、展開済ディレクトリまたはWARファイルからアプリケーションをデプロイできます。
標準のweb.xml
ファイルに指定されたセキュリティ制約はCommon Security Servicesのセキュリティ・プロバイダにマップされます。サーブレットAPIでは、宣言型のロール・ベース・セキュリティを指定します。つまり、特定のURLパターンをセキュリティ・ロールにマップできます。
config.xml
ファイルの次のスニペットはJetty構成の例を提供します - Jettyに関連する構成情報のみを示します:
例10-1 Jetty構成の例
<config> <netio> <name>JettyNetIO</name> <port>9002</port> </netio> <work-manager> <name>WM</name> <max-threads-constraint>64</max-threads-constraint> <min-threads-constraint>3</min-threads-constraint> </work-manager> <jetty> <name>TestJetty</name> <work-manager-name>WM</work-manager-name> <network-io-name>JettyNetIO</network-io-name> <debug-enabled>false</debug-enabled> <scratch-directory>JettyWork</scratch-directory> </jetty> <jetty-web-app> <name>test</name> <context-path>/test</context-path> <path>testWebApp.war</path> <jetty-name>TestJetty</jetty-name> </jetty-web-app> </config>