Apama 10.3.1 | Apama Documentation | Developing Apama Applications | Developing Apama Applications in EPL | Using Correlator Persistence | How the correlator recovers state
 
How the correlator recovers state
 
Recovery order
Defining recovery actions
Simplest recovery use case
When you restart a correlator for which persistence has been enabled the correlator
*Detects, recompiles, and re-injects all code that was injected and not deleted as of the last committed snapshot.
*Restarts and restores the state of all persistent monitors as of the last committed snapshot.
*Restarts non-persistent EPL monitors and JMon monitors at their onload() action.
*Executes any onBeginRecovery() and onConcludeRecovery() actions. See Defining recovery actions.
*Recovers persistent connections (connections created with engine_connect -p) and resumes them at the first opportunity.
Code is re-injected in the order in which it was originally injected. The correlator tracks which objects (monitors, events, Java objects) were deleted and does not re-inject them. Such objects might have been deleted explicitly with the engine_delete utility or implicitly as when all instances of a monitor have terminated. If a snapshot shows that an object was deleted and then re-injected, recovery ignores the first injection and re-injects the monitor or event at the point of its second injection.
For a persistent monitor, recovery appears to be a pause in processing. This pause has the potential to be long enough to cause some events to be stale. All non-persistent monitors appear to have spontaneously reverted to their onload state. Communication channels to external components have been interrupted and can be assumed to not yet be connected. Except, the correlator treats connections created with engine_connect -p, which are persistent connections, the same as it treats persistent state. Persistent connections continue until you explicitly remove them. Upon recovery, the correlator tries to reconnect to the external components that were connected with persistent connections. However, events sent or received after the last committed snapshot might have been dropped because there is no reliable delivery on persistent connections.
For a non-persistent monitor, recovery appears the same as starting the correlator. The correlator's current time is up-to-date. The monitor is in the state it would be if it were just injected. External components have not yet connected to the correlator. If a monitor initiates a request of a non-persistent monitor, then the non-persistent monitor might have to queue the request until a connection is made to an external component, for example, the correlator subscribes to a data stream from an external adapter.

Copyright © 2013-2019 | 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.