IEP Service Engine

The following are known issues for the IEP Service Engine:

• Issue 449

  When using Oracle as the IEP database platform, you must use Oracle JDBC driver version 10.2.0.4.0 or above. The default driver included with Oracle 9.2 (ojdbc14.jar) is version 9.0.2.0.0, and will not work with IEP. To determine the driver version you are using, view the manifest.mf file in the driver JAR file.

• OJC Issue 608

  When a cluster instance is stopped using the asadmin stop-instance command, IEP processes that are currently running do not fail over to a live instance. This is due to the order in which methods are called during the stop process.

  To work around this issue, stop and restart the Service Assembly.

• Issue 1311

  The relation aggregator does not work as expected for various operations, and the output is an incorrect number of events. For example, invalid aggregations are not removed for Oracle. In certain cases with Derby, aggregations are updated even if the aggregation has not changed, leading to extra events.

• Issue 1519

  When running the IEP SE on Solaris SPARC using an Oracle database, connection errors might occur.

  To work around this issue, restart the GlassFish server.

• Issue 1882

  When IEP SE is running on Solaris SPARC and using a Derby database, not all events are processed. This is due to an issue with a JDK method used by the IEP SE to get the current timestamp.

  To verify whether you are having this issue, send events to an IEP application and verify the timestamp.

• Issue 1986

  When the IEP SE is configured for Oracle and a RelationStream operator is used to retrieve events from an input relation, duplicate events may be produced.

  To work around this issue, use an InsertStream operator instead of RelationStream. Another option is to use a Distinct operator after the RelationStream operator to filter duplicates. Note that neither of these options may be able to completely replace RelationStream

• The IEP Service Engine creates connection pools and JDBC resources during installation. This automatic creation takes place only when the IEP Service Engine is installed in a GlassFish Domain Administration Server (DAS) instance. If the IEP Service Engine is installed in a GlassFish standalone instance, then the IEP Service Engine does not create the connection pools and JDBC resources.

  To work around this issue, manually create the connection pools and JDBC resources and then install the IEP Service Engine.

• An IEP Module project can have multiple event processors, and one database connection is created and kept open for each event processor. Therefore, each event processor has a dedicated database connection. When the event processors stop running (for example, when the Composite Application is stopped), this connection is released. Because the IEP SE uses database connections for other tasks, the maximum pool size of the connection pools should be larger than the number of event processors that are running in the IEP SE by a count of 10.

• By default, the IEP SE generates a WSDL document for each IEP process document, and regenerates the WSDL document every time the IEP process is edited. By default, bindings and services are generated in this WSDL, and these elements usually need to be edited to work properly when deployed. However, if these WSDL documents are edited, the edits are replaced by the default values every time the WSDL document is regenerated.

  Bindings and services created in the CASA Editor are not affected when the IEP WSDL documents are regenerated. However, you should not clone the IEP WSDL file to customize its generated bindings and services in the CASA Editor because updates to the generated WSDL files are not updated after cloning. Over time, the cloned and edited WSDL deployed for the bindings becomes inconsistent with the WSDL document deployed for the IEP Service Engine. Consider using the following procedure for setting up your Composite Application and IEP project for iterative development:

  1. Define the IEP Module project.

  2. Turn off the generation of concrete configuration elements (bindings and services) in the IEP generated WSDL files by setting the always.generate.abstract.wsdl flag in the project.properties file to true.

  3. Build the IEP Module project.

  4. Add the IEP Module project to a new Composite Application project and build the project.

  5. Define the binding components and connections using the CASA Editor. To use the composite application test feature, define SOAP input and file output bindings as appropriate for your test environment.

  6. Build and deploy the composite application.

  7. Run tests.

  8. Change the IEP Module project, adjust binding component and service configurations if necessary in the CASA Editor, and rebuild and redeploy the composite application. Run tests and repeat.