Developing Apama Applications > Developing Apama Applications in EPL > Implementing Parallel Processing > How contexts affect other parts of your Apama application > About replay logs and parallel processing
About replay logs and parallel processing
As mentioned before, applications that implement parallel processing might have non-deterministic behavior. However, you can still inject a parallel application into a correlator that you started with the --replayLog option. In this situation, the correlator records special pseudo-events that capture non-deterministic behavior in the replay log. This is in addition to recording all external events as usual.
To replay correlator behavior, including all non-deterministic decisions, specify the --replayMode argument when you start the correlator that will be reproducing the behavior captured in the replay log. Specify --replayMode in addition to the other options described in the correlator utilities section of the deployment guide.
See Reproducing correlator behavior from a replay log in the correlator utilities section of Deploying and Managing Apama Applications.
There are some limitations on how you can modify the EPL that you are injecting when reproducing parallel processing behavior from a replay log. In the code that you replay, the following must all be the same as they were when the behavior was captured in the replay log:
*emit, enqueue...to, and spawn...to operations
*Calls to context constructors
*Calls to the integer.getUnique() method
For applications that use multiple contexts or that enqueue events, just re-sending the events and EPL sent to the correlator is insufficient to reproduce the same output and state. The timing of which context ran which emit, enqueue...to or other operation is important. Operations that can affect the state of other contexts or the emitted events are non-deterministic when run in parallel.
If a replay log is incomplete, it might not have sufficient information to process all events sent to it. For example, the non-deterministic behaviour that occurred when generating the replay log could be unknown. Incomplete replay logs can occur in the unlikely event that the correlator stopped while processing events, for example if it ran out of memory, was killed, or crashed. There is no simple way of determining if the replay log is incomplete other than attempting to run it and seeing if the correlator does process all events on the contexts’ input queues.
It is possible to run the replay log extract script with the --noReplayMode option and then run the correlator with the –-replayMode option. Running the extract script with the --noReplayMode option does not extract the extra information needed to reproduce non-deterministic behavior in the original order. The correlator would then process all events, but the behavior (in terms of what events are emitted and what state monitors hold) might be significantly different if your EPL makes use of multiple contexts.
Copyright © 2013 Software AG, Darmstadt, Germany and/or Software AG USA Inc., Reston, VA, USA, and/or Terracotta Inc., San Francisco, CA, USA, and/or Software AG (Canada) Inc., Cambridge, Ontario, Canada, and/or, Software AG (UK) Ltd., Derby, United Kingdom, and/or Software A.G. (Israel) Ltd., Or-Yehuda, Israel and/or their licensors.