IEP サービスエンジンに関する既知の課題を次に示します。
IEP データベースプラットフォームとして Oracle を使用する場合、Oracle JDBC ドライバのバージョン 10.2.0.4.0 以上を使用する必要があります。Oracle 9.2 に含まれているデフォルトのドライバ ( ojdbc14.jar) は、バージョン 9.0.2.0.0 で、IEP では動作しません。使用しているドライバのバージョンを確認するには、ドライバ JAR ファイルの manifest.mf ファイルを確認してください。
asadmin stop-instance コマンドを使用してクラスタインスタンスを停止するときに、現在実行中の IEP プロセスが動作中のインスタンスにフェイルオーバーしません。これは、停止プロセス中に呼び出されるメソッドの順序が原因です。
この課題を回避するには、サービスアセンブリを停止して再起動します。
IEP SE は、高可用性モードおよびフェイルオーバーモードで、意図したとおりに動作しません。IEP SE の 2 つのインスタンスがある場合に、プロジェクトをインスタンス 1 に配備したあとインスタンス 2 に配備すると、インスタンス 1 は通常の状態で出力を生成します。インスタンス 2 からプロジェクトの配備を取り消したあと、インスタンス 1 から配備を取り消し、続いてインスタンス 2 にプロジェクトを再配備してから、インスタンス 1 に再配備した場合、インスタンス 2 が出力を生成するべきです。実際には、インスタンス 1 とインスタンス 2 の両方が出力を生成します。
この課題を回避するには、インスタンス 2 で IEP SE を再起動します。
この課題は、以前のバージョンの Java CAPS からアップグレードする場合にのみ適用されます。パッチを適用して、GlassFish アプリケーションサーバーを起動したあと、IEP サービスエンジンが Java DB に接続できないか、iepseDB が存在しないことを示す例外を返します。
この課題を回避するには、次の手順を実行して、IEP サービスエンジンをアンインストールしたあとに再インストールします。
NetBeans IDE の「サービス」ウィンドウで、「サーバー」、「GlassFish V2」、「JBI」、「サービスエンジン」の順に展開します。
「sun-iep-engine」を右クリックし、「アンインストール」を選択します。IEP サービスエンジンがアンインストールされます。
GlassFish 管理コンソールを起動します。
左側のナビゲーションパネルで、「リソース」、「JDBC」の順に展開し、「JDBC リソース」を選択します。
jdbc/iepseDerbyXA および jdbc/iepseDerbyNonXA という名前のリソースを削除します。
iepseDB ディレクトリが install-dir/.netbeans-derby ディレクトリにある場合は、NetBeans IDE からログアウトして、iepseDB ディレクトリを削除します。
NetBeans IDE を再起動したあと、GlassFish アプリケーションサーバーを再起動します。
「NetBeans サービス」ウィンドウで、「サービスエンジン」を右クリックし、「インストールして起動」を選択します。
表示されたウィンドウで、install-dir/appserver/domains/domain1/jbi/autoinstall を参照し、iepserviceengine.jar ファイルを選択します。
デフォルトの設定をそのまま使用して、「インストール」をクリックします。IEP サービスエンジンがインストールされ、Java DB (iepseDB) に正常に接続されます。
IEP データベースが Oracle を使用するように設定されている場合、Union 演算子が意図したとおりに動作しません。あるテストケースでは、2 つの Relation Aggregator 演算子が Union 演算子に結合されました。出力には 7 つのイベントが含まれると予想されました。実際には、出力には 3 つのイベントしか含まれませんでした。別のテストケースでは、2 つの Time Based Window 演算子が Union 演算子に結合されました。Time Based Window 演算子の一方で受信したイベントごとに、Union 演算子は期待どおりに計算されます。ただし、Time Based Window 演算子が期限切れになるときに、Union 演算子が再計算されます。これは正しくないように思われます。
関係集約機能は、さまざまな演算子で期待どおりに動作せず、出力のイベント数が正しくありません。たとえば、Oracle では無効な集約が削除されません。Derby では、集約が変更されていない場合にも集約が更新され、余分なイベントが発生する場合があります。
Solaris SPARC で、Oracle データベースを使用して IEP SE を実行しているときに、接続エラーが発生する場合があります。
この課題を回避するには、GlassFish サーバーを再起動します。
Solaris SPARC で IEP SE を実行して、Derby データベースを使用している場合、一部のイベントが処理されません。これは、IEP SE が現在のタイムスタンプの取得に使用する、JDK のメソッドに関する課題が原因です。
この課題が発生しているかどうかを確認するには、IEP アプリケーションにイベントを送信して、タイムスタンプを確認します。
IEP SE を Oracle 用に設定していて、RelationStream 演算子を使用して入力リレーションからのイベントを取得するときに、重複するイベントが生成される場合があります。
この課題を回避するには、RelationStream の代わりに InsertStream 演算子を使用します。別の方法として、RelationStream 演算子のあとに Distinct 演算子を使用して、重複をフィルタ処理します。これらの方法は、どちらも RelationStream を完全に置き換えることはできません。
IEP サービスエンジンは、インストール中に接続プールと JDBC リソースを作成します。この自動作成は、IEP サービスエンジンを GlassFish ドメイン管理サーバー (DAS) のインスタンスにインストールする場合にのみ実行されます。IEP サービスエンジンを GlassFish のスタンドアロンインスタンスにインストールする場合、接続プールと JDBC リソースは作成されません。
この課題を回避するには、接続プールと JDBC リソースを手動で作成したあと、IEP サービスエンジンをインストールします。
1 つの IEP モジュールプロジェクトに複数のイベントプロセッサが含まれる場合があり、各イベントプロセッサに対して 1 つのデータベース接続が作成され、開いた状態が維持されます。したがって、各イベントプロセッサは専用のデータベース接続を使用します。イベントプロセッサが停止すると (たとえば、複合アプリケーションが停止した場合)、この接続は解放されます。IEP SE はほかのタスクでもデータベース接続を使用するため、接続プールの最大プールサイズは、IEP SE で動作しているイベントプロセッサの数の 10 倍にしてください。
デフォルトでは、IEP SE は IEP プロセスドキュメントごとに WSDL ドキュメントを生成し、IEP プロセスが編集されるたびに WSDL ドキュメントを再生成します。デフォルトでは、接続とサービスはこの WSDL に生成され、配備時に正しく機能させるために、通常はこれらの要素を編集する必要があります。ただし、これらの WSDL ドキュメントを編集する場合、WSDL ドキュメントが生成されるごとに、編集内容がデフォルト値で上書きされます。
CASA エディタで作成された接続とサービスは、IEP WSDL ドキュメントが再生成されるときに影響を受けません。ただし、IEP WSDL ファイルを複製して、生成された接続とサービスを CASA エディタでカスタマイズしないでください。生成された WSDL ファイルに対する更新が、複製後に更新されなくなります。時間の経過とともに、接続に配備した複製および編集した WSDL が、IEP サービスエンジンに配備した WSDL ドキュメントと矛盾するようになります。繰り返し型の開発で複合アプリケーションと IEP プロジェクトを設定する場合は、次の手順の使用を検討してください。
IEP モジュールプロジェクトを定義します。
project.properties ファイルで always.generate.abstract.wsdl フラグを true に設定して、IEP が生成した WSDL ファイルでの具象構成要素 (接続とサービス) の生成を無効にします。
IEP モジュールプロジェクトをビルドします。
IEP モジュールプロジェクトを新しい複合アプリケーションプロジェクトに追加して、プロジェクトをビルドします。
接続コンポーネントと接続を、CASA エディタを使用して定義します。複合アプリケーションのテスト機能を使用するには、SOAP 入力とファイル出力の接続をテスト環境に適切となるように定義します。
複合アプリケーションをビルドして配備します。
テストを実行します。
IEP モジュールプロジェクトを変更し、CASA エディタで接続コンポーネントとサービスの設定を必要に応じて調整し、複合アプリケーションを再ビルドおよび再配備します。テストの実行を繰り返します。