Miscellaneous changes in 9.10 affecting backwards compatibility
With previous versions, the EPL coassignment mechanism allowed coassignments from different triggerings of a listener instance to leak into each other. For example, consider the following code:
A a := A(0);
B b := B(0);
on all (A():a or B():b) {
print a.toString() + " " + b.toString();
}
Previously, sending A(1) and B(1) printed the following, where the coassignment of A(1) carried over into the triggering of the listener caused by B(1):
A(1) B(0)
A(1) B(1)
This has been corrected in this version so that the above code will now print the following:
A(1) B(0)
A(0) B(1)
This change may also cause a slight reduction in memory usage and an increase in performance of persistent applications.
The
isExternal() method on events in EPL has changed behavior. While in previous releases, the
route,
send..to or
enqueue..to statements would change an event to always be internal, in 9.10, these do not modify the
isExternal() property. For example, an external event that is forwarded to a second context will still appear to be external. The
clone() method always returns an internal event, so if an internal event is required, then
enqueue evt.clone() to target will give the same behavior as previous releases.
Apama now ships with the files
QueryServices.cdp and
SetSingleContext.cdp instead of
QueryServices.mon and
SetSingleContext.mon. That is, correlator deployment packages are now provided instead of EPL files.
The Apama extensions to the PySys testing framework now perform a clean shutdown of correlators and IAFs before the test ends, rather than terminating the process without warning. This makes it easier to detect problems associated with the shutdown, and it also allows code coverage information to be retrieved. If you want to disable this new behavior, add the boolean property
shutdownApamaComponentsAfterTest to the project file.
When a launch configuration is created for a project in Software AG Designer, the name
defaultCorrelator is now used. Backwards compatibility is provided for the Apama projects that you have created with previous versions: the name
Default Correlator is automatically considered as
defaultCorrelator.
However, if you still have Apama projects that have been created before version 5.2 and if these projects have adapter configurations that use the ${Default Correlator.port} and ${Default Correlator.hostname} properties and do not have any launch configurations, the Ant export of these projects will not work seamlessly. As a workaround, you have to apply any of the following changes to these projects:
1. When a launch configuration has been created in Software AG Designer which uses the name defaultCorrelator, change this back to the old Default Correlator name.
2. Use the new properties in your adapter configuration. That is, change the old ${Default Correlator.port} and ${Default Correlator.hostname} properties to ${defaultCorrelator.port} and ${defaultCorrelator.hostname}.
3. Modify the Ant exported environment.properties file and add the value Default Correlator.port=portValue.
The random number generator in the Apama correlator has been updated to provide higher resolution and improved performance. This change will result in different sequences of random numbers being produced and as such any code or tests which rely on specific sequences of random numbers via seed values (provided, for example, via the
-XsetRandomSeed option of the
correlator executable) or which use the "replay log" feature will need to be updated.
Performance improvements in this version have eliminated the need for different correlator scheduler types. The
--scheduler option has therefore been removed from the
correlator executable. Note that the correlator will fail to start up if you continue to use this option.
The location of Apache Ant which is shipped with Apama has been changed and it can now be found in the
third_party\apache_ant directory of your Apama installation. If you have customized any scripts to rely on the previous location, we recommend that you test your scripts carefully to ensure that they work as expected.
The correlator now uses separate Java child classloaders for loading the libraries required for distributed MemoryStore and JMS support, which substantially reduces the number of libraries present in the top-level system classloader that all correlator, connectivity, JMS and distributed MemoryStore plug-ins share, and therefore reduces the potential for library conflicts between them and customer plug-ins. In previous versions it was possible (though not recommended) to start the correlator with distributed MemoryStore and JMS configuration files in the same directory; this is no longer possible and will result in "Failed to initialize correlator: [ADAPTER_NAME] configuration is invalid: Line XX in XML document from URL..." errors.
To avoid class not found problems, ensure you are specifying classpaths using the settings in the relevant XML configuration files for JMS and distributed MemoryStore rather than using command-line options that change the correlator's system classpath such as -J-Djava.class.path. The vast majority of applications will be doing this already and will require no modification. In some situations, if your plug-in or a library it depends upon uses the context (thread-specific) classloader to locate classes, it may also be necessary to set that explicitly using the following:
Thread.currentThread().setContextClassLoader(
YourClassHere.class.getClassLoader() )