Apama Documentation : Developing Apama Applications : Developing Apama Applications in EPL : Using Correlator Persistence : How the correlator persists state
How the correlator persists state
When persistence is enabled the correlator periodically writes data to disk to reflect the correlator's runtime state. To do this, the correlator
1. Suspends all execution in the correlator across all contexts.
2. Takes an in-memory snapshot of what needs to be stored.
3. Resumes processing while the state is written to disk.
The correlator waits to suspend execution until all contexts have completed any in-progress event processing and any in-progress deletions. It can take time for the correlator to pause all contexts. Consequently, it is best practice that a single event listener does not take a long time to process. When there is a need to perform a large amount of work try to split the work across multiple events.
How fine-grained to split work depends on the performance requirements of the application. Avoid very fine-grained work units as the overhead of scheduling will start to dominate and lead to the application running slowly.
Committing the snapshot to disk is an atomic operation. That is, a failure while storing state reverts the stored data to the previously successfully stored snapshot.
By default, when you enable persistence the correlator does the following:
*Takes a snapshot of state changes every 200 milliseconds. This is the snapshot initerval. The correlator tracks the in-memory objects that have changed since the last snapshot and writes only that state to disk. If only a small fraction of the correlator's state changes then only a fraction of the correlator's state must be stored for each snapshot.
*Automatically adjusts the snapshot interval. For example, if a significant percentage of the correlator's state changes then the correlator increases the snapshot interval, so that the overall throughput is not adversely affected.
*Stores persistent state in the current directory, which is the directory in which the correlator was started.
*Uses persistence.db as the name of the file that contains persistent state. This is the recovery datastore.
*Copies the recovery datastore to the input log if one was specified when the correlator was started. This happens only upon restarting the correlator.
*For applications that do not use the correlator's internal clock (correlators started with the -Xclock option), the correlator uses the time of day in the last committed snapshot as the current time in the restarted correlator.
Copyright © 2013-2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback