ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Event Processing管理者ガイド
11gリリース1 (11.1.1.7)
B61653-06
  目次へ移動
目次
前
前 		 次
次		  

11 Oracle Event Processing用のJettyの構成

この章は、Oracle Event Processingで使用するJettyの構成方法を、ネットワークI/Oの構成、ワーク・マネージャと、Jettyサーバー・インスタンスの構成を含めて説明します。

この章の内容は次のとおりです。

11.1 Oracle Event ProcessingにおけるJettyサポートの概要

Oracle Event Processingでは、HTTPサーブレットと静的リソースをデプロイするJava WebサーバーとしてJetty(http://www.mortbay.org/を参照してください)がサポートされています。

Oracle Event ProcessingでのJettyサポートは、バージョン1.2のOSGi HTTPサービスに基づいています。このAPIでは、実行時リソースと静的リソースにhttp://java.sun.com/products/servlet/docs.htmlオブジェクトを動的に登録および登録解除する機能が提供されます。この仕様には、JavaサーブレットAPIバージョン2.1以上が必要です。

Oracle Event Processingでは、Jettyの次の機能をサポートします。

Jettyの構成の詳細は、11.2項「Jettyサーバー・インスタンスの構成」を参照してください。

11.1.1 サーブレット

Oracle Event Processingでは、一般的な(同期) Javaサーブレットをサポートするだけでなく、非同期サーブレットもサポートします。非同期サーブレットはリクエストを受信し、スレッドを取得して作業を実行します。また、最終的には、アクションの完了を待機している間に(別のスレッドを再取得するよりも前に)スレッドを解放し、レスポンスを送信します。

11.1.2 ネットワークI/Oの統合

Oracle Event Processingでは、ネットワークI/O (NetIO)を使用してJettyサービスのポートとリスニング・アドレスを構成します。


注意:

Jettyは多重化されたネットワークI/Oに対応した組込み機能を備えています。ただし、同一ポート上での複数のプロトコルはサポートされません。

11.1.3 スレッド・プールの統合

Oracle Event Processing Jettyサービスは、Oracle Event Processingワーク・マネージャを使用して、スケーラブルなスレッド・プーリングを可能にします。11.3項「Jetty構成の例」を参照してください。


注意:

JettyにはJetty独自のスレッド・プール機能が用意されています。ただし、処理コストおよび構成の複雑さを最小限に抑えるために、Oracle Event Processingの自動チューニング・スレッド・プールを使用することをお薦めします。

11.1.4 Jettyワーク・マネージャ

Oracle Event Processingでは、アプリケーションがどのような優先順位で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメントが維持されます。ワーク・マネージャを定義して、アプリケーションに対してルールや制約を定義します。

この項では次の内容について説明します。

詳細は、11.2.3項「work-manager構成オブジェクト」を参照してください。

11.1.4.1 Oracle Event Processingでのスレッド・プールの使用方法の理解

Oracle Event Processingでは、1つのスレッド・プールですべてのタイプの作業を実行します。Oracle Event Processingでは、作業の優先順位は、ユーザーが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際にリクエストを実行するのにかかった時間、リクエストをプールに出し入れする割合などがあります。

共通スレッド・プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニターし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、Oracle Event Processingではスレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、Oracle Event Processingではスレッド数が自動的に減らされます。

11.1.4.2 ワーク・マネージャの構成の理解

Oracle Event Processingでは、定義済のパラメータと実行時のパフォーマンスおよびスループットを考慮に入れた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。

ユーザーは、一連のスケジューリング・ガイドラインを構成し、それらを1つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション・コンポーネントに関連付けたりできます。たとえば、スケジューリング・ガイドラインのセットを1つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、Oracle Event Processingではこれらのガイドラインに基づいて、保留中の作業やキューに入っているリクエストが実行スレッドに割り当てられます。

アプリケーション内の作業を管理するには、次のうち1つまたは複数のワーク・マネージャ・コンポーネントを定義します:

  • fairshare: リクエストを処理するのに必要な平均スレッド使用時間を指定します。

    たとえば、Oracle Event Processingで2つのモジュールを実行しているとします。ModuleAのワーク・マネージャではfairshareが80に指定されていて、ModuleBのワーク・マネージャではfairshareが20に指定されています。

    各モジュールで切れ目なくリクエストを処理している状態(つまり、リクエスト数がスレッド数を超えている状態)が続く間は、Oracle Event Processingでは、スレッド使用時間の80%がModuleAに、20%がModuleBにそれぞれ割り当てられます。


    注意:

    フェア・シェア・リクエスト・クラスの値は、割合ではなく相対値で指定します。したがって、上の例でリクエスト・クラスを400と100に設定しても相対値としては同じです。

  • max-threads-constraint: この制約は、制約対象の作業セットからのリクエストを実行する同時スレッドの数を制限します。デフォルトは無制限です。たとえば、最大スレッド数が10に定義された制約を3つのエントリ・ポイントで共有するとします。このスケジューリング・ロジックでは、組み合せた3つのエントリ・ポイントからのリクエストを10個以下のスレッドで実行します。

    max-threads-constraintは、リクエストが依存するリソース(たとえば接続プール)の可用性の観点から定義できます。

    max-threads-constraintは、リクエスト・クラスによるスレッドのフェア・シェアの実現やレスポンス時間の目標値の達成を妨げることがあります。いったん制約条件が満たされると、同時実行数が制限値を下回るまで、Oracle Event Processingではこのタイプのリクエストはスケジューリングされません。制限値を下回ると、Oracle Event Processingでは、フェア・シェアまたはレスポンス時間の目標値に基づいて作業がスケジューリングされます。

  • min-threads-constraint: この制約は、制約対象のリクエストに割り当てられるスレッド数を保証することでデッドロックを回避します。デフォルトはゼロです。min-threads-constraintの値を1に設定すると、ピアから同期的に呼び出されるレプリケーション更新リクエストなどの場合に便利です。

    min-threads-constraintによってフェア・シェアが向上するとはかぎりません。このタイプの制約は、主にOracle Event Processingインスタンスがデッドロック状態に近づいたときに効果を発揮します。このような場合は、最近サービス・クラス内のリクエストがフェア・シェアを超えていた場合でも、Oracle Event Processingではこの制約によってリクエストがスケジューリングされます。

11.2 Jettyサーバー・インスタンスの構成

Oracle Event Processingドメインを記述するconfig.xmlファイル内にJetty HTTPサーバーのインスタンスを構成するには、次の構成オブジェクトを使用します。

Jettyに影響を与えるセキュリティ構成タスクの詳細は、10.8.1項「Jettyセキュリティの構成」を参照してください。

詳細は、次を参照してください:

11.2.1 jetty構成オブジェクト

次の表に示すパラメータを使用して、config.xmlファイルにjetty構成オブジェクトを定義します。

表11-1 jetty要素の構成パラメータ

パラメータ タイプ 説明 
network-io-name

String

使用するNetIOサービスの名前。NetIOサービスは、サーバーがリスニングするポートを定義します。

詳細は、11.2.2項「netio構成オブジェクト」を参照してください。

 
work-manager-name

String

スレッド・プール用に使用するワーク・マネージャの名前。指定しない場合はデフォルトのワーク・マネージャが使用されます。

11.2.3項「work-manager構成オブジェクト」を参照してください。

 
scratch-directory

String

Webアプリケーション、JSPおよびその他のタイプのWebアーティファクトに必要な一時ファイルを保管するディレクトリの名前。

 
debug-enabled

boolean

JettyコードでOSGi Log Serviceを使用してデバッグ機能を有効にします。

 
name

String

jettyサーバー・インスタンスの名前。

11.2.2 netio構成オブジェクト

次の表に示すパラメータを使用して、config.xmlファイルにnetio構成オブジェクトを定義します。

表11-2 netio要素の構成パラメータ

パラメータ タイプ 説明 
name

String

この構成オブジェクトの名前。

 
port

int

リスニングするポート番号。

 
listen-address

String

netioサービスのインスタンスが着信接続をリスニングするアドレス。

  • このパラメータは、a.b.c.d形式の数値IPアドレスまたはホスト名に設定できます。

  • 設定しない場合は、すべてのネットワーク・インタフェースがリスニングされます。

このパラメータの値は、サービスが起動されるまで検証できません。

11.2.3 work-manager構成オブジェクト

次の表に示すパラメータを使用して、config.xmlファイルにwork-manager構成オブジェクトを定義します。

表11-3 work-manager要素の構成パラメータ

パラメータ タイプ 説明 
min-threads-constraint

Integer

このワーク・マネージャが使用する最小スレッド数。

 
fairshare

Integer

このワーク・マネージャが使用するフェア・シェア値。

 
max-threads-constraint 

Integer

このワーク・マネージャが使用する最大スレッド数制約。

 
name 

String

このワーク・マネージャの名前。

11.2.4 jetty-web-app構成オブジェクト

次の構成オブジェクトを使用して、Jettyが使用するWebアプリケーションを定義します。

表11-4 jetty-web-app要素の構成パラメータ

パラメータ タイプ 説明 
context-path

String

このWebアプリケーションのデプロイ先となるWebサーバーのネームスペースのコンテキスト・パス。

設定しない場合、デフォルトで「/」になります。

 
scratch-directory

String

JettyがこのWebアプリケーションの一時ファイルを保管する場所。

11.2項「Jettyサーバー・インスタンスの構成」のscratch-directoryパラメータをオーバーライドします。

 
path

String

サーバー上のWebアプリケーションの場所を指すファイル名。ディレクトリまたはWARファイルを指定できます。

 
jetty-name

String

このWebアプリケーションのデプロイ先のJettyサービス名。既存の11.2項「Jettyサーバー・インスタンスの構成」の名前と一致している必要があります。

 
name

String

この構成オブジェクトの名前。

11.2.5 Jetty対応サーブレットの開発

Oracle Event Processingでは、Jettyにデプロイするサーブレットの開発をサポートしています。標準のJava EE Webアプリケーションを作成し、11.2.4項「jetty-web-app構成オブジェクト」を使用してアプリケーションを構成します。

11.2.6 Webアプリケーション・デプロイメント

Oracle Event Processingでは、Java Servletバージョン2.4仕様に規定されているように、WARファイルまたは展開されたWARファイルのどちらでもパッケージのデプロイメントをサポートしています。

事前に構成されたWebアプリケーションをサーバーの構成に組み込むことによって、展開済ディレクトリまたはWARファイルからアプリケーションをデプロイできます。

標準のweb.xmlファイルに指定されたセキュリティ制約はCommon Security Servicesのセキュリティ・プロバイダにマップされます。サーブレットAPIでは、宣言型のロール・ベース・セキュリティを指定します。つまり、特定のURLパターンをセキュリティ・ロールにマップできます。

11.3 Jetty構成の例

config.xmlファイルの次のスニペットはJetty構成の例を提供します - Jettyに関連する構成情報のみを示します:

例11-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>
  前
前 		 次
次
  目次へ移動
目次