Apama 10.3 | Apama Documentation | Deploying and Managing Apama Applications | Correlator Utilities Reference | Starting the correlator | Injection time of compiled runtime
Injection time of compiled runtime
Injection times for systems using the compiled runtime can be very long - significantly longer than if using only the interpreted runtime. Subsequent injection times can be improved by using the --runtime-cache dir option, which specifies a directory where the correlator can cache the compilation state (see Starting the correlator). This stores the results of compiling EPL code on disk to be used for subsequent injections of the same code.
The compiled EPL code is specific to the system on which it was compiled and the version of Apama that was used to compile it. This means that while a cache can be moved or shared between machines to improve startup on a new machine, it must be identical to the original. Otherwise, the cached version cannot be used and it must be recompiled
An injection is able to use a cached version of a previous injection if all of the following are the same as in a previous injection:
*The EPL source code.
*The source code of all files that contain any type that an injection depends on.
*The correlator version.
*The host operating system.
*The CPU model.
The results of injections can be affected by any of the above. Therefore, if any change occurs, the correlator will re-compile the EPL.
The cache is designed to be used to speed up re-injection on production systems and not for quicker development cycles, which should typically use the interpreter for faster injection times. If there are identical user acceptance testing (UAT) and production environments, then the UAT environment can prime a cache which can then be used by the production correlator to improve initial startup times. However, the two systems must be identical. The strings used to disambiguate systems are logged at correlator startup when using the compiled runtime and can be used to compare the systems.
The cache contents are never removed by the correlator. If you change your source, correlator versions or platform, then the cache may grow and contain stale items which are no longer needed. If cache sizes become a problem, then we either recommend deleting the entire cache, or just the cache files with the oldest timestamps. The correlator will transparently recompile any needed files which are missing from the cache.

Copyright © 2013-2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.