Known Issues for the 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 1083

  The IEP SE might not work as expected in high availability and failover mode. When there are two instances of the IEP SE and a project is deployed on instance 1 and then on instance 2, instance 1 generates the output in normal conditions. If you undeploy the project from instance 2 and then from instance 1, and then redeploy the project on instance 2 and then on instance 1, instance 2 should generate the output. Instead, both instance 1 and instance 2 generate the output.

  To work around this issue, restart the IEP SE on instance 2.

• Issue 1184

  This issue applies only to upgrading from previous versions of Java CAPS. After the patches are applied and the GlassFish application server is started, the IEP Service Engine might be unable to connect to Java DB or might return exceptions indicating that iepseDB does not exist.

  To work around this issue, uninstall and then reinstall the IEP Service Engine by performing the following steps:

  1. In the Services window of the NetBeans IDE, expand Servers > GlassFish V2 > JBI > Service Engines .

  2. Right-click sun-iep-engine and select Uninstall. The IEP Service Engine is uninstalled.

  3. Launch the GlassFish Admin Console.

  4. In the Navigation panel on the left, expand Resources and expand JDBC, and select JDBC Resources.

  5. Delete the resources named jdbc/iepseDerbyXA and jdbc/iepseDerbyNonXA.

  6. If the iepseDB directory exists in the install-dir/.netbeans-derby directory, log out of the NetBeans IDE and remove the iepseDB directory.

  7. Restart the NetBeans IDE and then restart the GlassFish application server.

  8. In the NetBeans Services window, right-click Service Engines and select Install and Start.

  9. In the window that appears, browse to install-dir/appserver/domains/domain1/jbi/autoinstall and select the iepserviceengine.jar file.

  10. Accept the default configuration and click Install. The IEP Service Engine is installed and connected to Java DB (iepseDB) successfully.

• Issue 1187

  When the IEP database is configured to use Oracle, the Union operator may not work as expected. In a test case, two Relation Aggregator operators were connected to the Union operator. The output was expected to contain seven events. However, the output contained only three events. In another test case, two Time Based Window operators were connected to the Union operator. For every event that is received by one of the Time Based Window operators, the Union operator is calculated as expected. However, the Union operator is recalculated when the Time Based Window operator expires, which seems to be incorrect.

• 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.