Reproducing correlator behavior from an input log
To use an input log to reproduce correlator behavior, you must do the following:
1. Run the extract_replay_log Python utility.
2. Run the replay_execute script that the extract_replay_log utility generates.
Invoking the extract script
The
extract_replay_log.py script is in the
utilities directory in your Apama installation directory. You must have at least Python 2.4 to run this utility. You can download Python from
http://www.python.org. If you are using Linux, you probably already have Python installed.
The format for running the extract_replay_log utility is as follows:
extract_replay_log.py [options] inputLogFile
Replace inputLogFile with the path for the input log you want to extract. If you specify the first input log in a series, the subsequent input logs must be in the same directory as the first input log.
The options you can specify are as follows:
Option | Description |
-o=dir or --output=dir | Specifies the directory that you want to contain the output from the extract_replay_log utility. The default is the current directory. |
-l=lang or --lang=lang | Specifies the language of the script that the extract_replay_log utility generates. Replace lang with one of the following:  shell generates the replay_execute.sh UNIX shell script. batch generates the replay_execute.bat Windows batch file. This is the default. |
-c or --correlator | Specifies that the script that extract_replay_log generates should include the command line for starting a correlator. When you run the generated script, the correlator will be started with all of the command line options needed to replay the input log. |
-v or --verbose | Indicates that you want verbose utility output. |
-h or --help | Displays help for the utility. |
The extract_replay_log utility generates the following:
A script whose execution duplicates the correlator activity captured by the input log.
Event files — each one is prefixed with
replay_.
EPL and possibly JAR and Correlator Deployment Package (CDP) files — each one is prefixed with
replay_.
Invoking the replay script
Before you run the replay script, you can optionally edit the generated event files, EPL files, or JAR files to slightly modify the behavior you are about to replay. For example, you might add logging for debugging purposes. However, there are restrictions on what you can change:
You cannot insert any of the following:
calls to
integer.getUnique() or
rand()send,
emit,
spawn...to,
enqueue, or
enqueue..to statements
context constructors
You cannot change the number of parseable events sent to the correlator. For example, you cannot attach a dashboard component to the input log because the dashboard components work by sending events to the correlator.
You cannot change the number of event definitions and monitors injected.
Making any of these changes can potentially alter the behavior of later operations.
If you are using the MemoryStore and the correlator reads or writes to a store on disk then to accurately play back execution you must have a copy of that store as it was before the correlator modified it. Also, if you are using the MemoryStore from multiple contexts it is unlikely to replay correctly because the order of interaction with the MemoryStore is not in the input log.
After you have optionally edited the generated files, you are ready to invoke the replay_execute script. The replay_execute script tries to replay the contents of the input log into the correlator running on the default port.
While the correlator exactly reproduces the activity captured in the input log, it can execute the same activity faster during replay than when it was executed originally. This is because the correlator already has all the events it needs to process; it does not have to wait for any events. Replaying a log is typically significantly faster than original correlator activity. It is possible that you will find that the time it takes to replay a log is not much less than the time it took for the original activity. In this case, it is possible you were running too close to capacity during the original run. If that is the case, you risk not being able to keep up with the event flow during regular correlator execution. If you anticipate higher event flow then you should investigate optimizing your application or running it on a faster computer.