管理およびコンフィグレーション ガイド

     前  次    新しいウィンドウで目次を開く     
ここから内容の開始

Oracle Complex Event Processing で使用する Jetty のコンフィグレーション

この節では、以下の項目について説明します。

 

Oracle Complex Event Processing の Jetty サポートの概要

Oracle Complex Event Processing (略称 Oracle CEP) では、HTTP サーブレットおよび静的リソースをデプロイする Java Web サーバとして Jetty がサポートされています。

Oracle CEP での Jetty サポートは、バージョン 1.2 の OSGi HTTP サービスに基づいています。この API では、実行時リソースと静的リソースに javax.servlet.Servlet オブジェクトを動的に登録および登録解除する機能が提供されます。この仕様には、Java Servlet API バージョン 2.1 以上が必須です。

Oracle CEP では、Jetty の以下の機能をサポートします。

Jetty のコンフィグレーションの詳細については、「Jetty サーバ インスタンスのコンフィグレーション」を参照してください。

サーブレット

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

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

Oracle CEP では、ネットワーク I/O (NetIO) を使用して Jetty サービスのポートとリスン アドレスをコンフィグレーションします。

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

スレッド プールの統合

Oracle CEP Jetty サービスは Oracle CEP ワーク マネージャを使用して、スケーラブルなスレッド プールを提供します。「Jetty コンフィグレーションの例」を参照してください。

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

ワーク マネージャ

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

Oracle CEP でのスレッド プールの使用について

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

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

ワーク マネージャについて

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

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

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

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

 

Jetty サーバ インスタンスのコンフィグレーション

Oracle CEP ドメインを記述する config.xml ファイル内に Jetty HTTP サーバのインスタンスをコンフィグレーションするには、以下のコンフィグレーション オブジェクトを使用します。

Jetty インスタンスに Web アプリケーションを定義するには、<jetty-web-app> コンフィグレーション オブジェクトを使用します。詳細については、「jetty-web-app コンフィグレーション オブジェクト」を参照してください。

上記の各コンフィグレーション オブジェクトを使用したサンプルについては、「Jetty コンフィグレーションの例」を参照してください。

jetty コンフィグレーション オブジェクト

次の表に示すパラメータを使用して、config.xml ファイルに <jetty> コンフィグレーション オブジェクトを定義します。

表 8-1 <jetty> のコンフィグレーション パラメータ
パラメータ
型
説明
network-io-name
String
使用する NetIO サービスの名前。NetIO サービスは、サーバがリスンするポートを定義します。
詳細については、「netio コンフィグレーション オブジェクト」を参照してください。
work-manager-name
String
スレッド プール用に使用するワーク マネージャの名前。指定しない場合はデフォルトのワーク マネージャが使用されます。
「work-manager コンフィグレーション オブジェクト」を参照してください。
scratch-directory
String
Web アプリケーション、JSP、およびその他のタイプの Web アーティファクトに必要な一時ファイルを保管するディレクトリの名前。

debug-enabled

boolean
Jetty コードで OSGi Log Service を使用してデバッグ機能を有効にします。
name
String
jetty サーバ インスタンスの名前。

netio コンフィグレーション オブジェクト

次の表に示すパラメータを使用して、config.xml ファイルに <netio> コンフィグレーション オブジェクトを定義します。

表 8-2 <netio> のコンフィグレーション パラメータ
パラメータ
型
説明
name
String
このコンフィグレーション オブジェクトの名前。
port
int
リスンするポート番号。
listen-address
String
netio サービスのインスタンスが着信接続をリスンするアドレス。
  • このパラメータは、a.b.c.d 形式の数値 IP アドレスまたはホスト名に設定できます。
  • 設定しない場合は、すべてのネットワーク インタフェースがリスンされます。

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

work-manager コンフィグレーション オブジェクト

次の表に示すパラメータを使用して、config.xml ファイルに <work-manager> コンフィグレーション オブジェクトを定義します。

表 8-3 <work-manager> のコンフィグレーション パラメータ
パラメータ
型
説明
min-threads-constraint
Integer
このワーク マネージャが使用する最小スレッド数。
fairshare
Integer
このワーク マネージャが使用するフェア シェア値。
max-threads-constraint
Integer
このワーク マネージャが使用する最大スレッド数制約。
name
String
このワーク マネージャの名前。

jetty-web-app コンフィグレーション オブジェクト

以下のコンフィグレーション オブジェクトを使用して、Jetty が使用する Web アプリケーションを定義します。

表 8-4 <jetty-web-app> のコンフィグレーション パラメータ
パラメータ
型
説明
context-path
String
この Web アプリケーションのデプロイ先となる Web サーバのネーム スペースのコンテキスト パス。
設定しない場合、デフォルトで "/" になります。
scratch-directory
String
Jetty がこの Web アプリケーションの一時ファイルを保管する場所。
「Jetty サーバ インスタンスのコンフィグレーション」の scratch-directory パラメータをオーバーライドします。指定しない場合、ディレクトリが作成されます。
path
String
サーバ上の Web アプリケーションの場所を指すファイル名。ディレクトリまたは WAR ファイルを指定できます。
jetty-name
String
この Web アプリケーションのデプロイ先の Jetty サービス名。既存の Jetty サーバ インスタンスのコンフィグレーションの名前と一致している必要があります。
name
String
このコンフィグレーション オブジェクトの名前。

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

Oracle CEP では、Jetty にデプロイするサーブレットの開発をサポートしています。標準の J2EE Web アプリケーションを作成し、jetty-web-app コンフィグレーション オブジェクトを使用してアプリケーションをコンフィグレーションします。

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

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

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

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

 

Jetty コンフィグレーションの例

config.xml ファイルから抜粋した以下のコードは、Jetty コンフィグレーションの例を示しています。ここでは、Jetty 関連のコンフィグレーション情報のみを示しています。

コード リスト 8-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>

  ページの先頭       前  次