3 \brief Explains how previously recorded logs can be used
4 as source of market data for further testing or analysis.
6 \section replaying-logs Using Logs to Replay Market Data
8 Under normal flow, the Handler logs all important aspects
9 of its execution. Logged events also include the original
10 market data processed by the Handler. Development and support
11 teams may use this information during investigations of non-standard
12 situations. However, it can be used to reproduce normal Handler's
13 behavior for a certain period of time.
15 The Handler can extract market data from a log file
16 if the OnixS::CME::MDH::FileLogger produced it.
18 \warning To get market data recorded into a log file, the
19 OnixS::CME::MDH::FileLoggerSettings::severityLevel parameter
20 must be set to either the OnixS::CME::MDH::LogSeverity::Regular
21 or the OnixS::CME::MDH::LogSeverity::Debug value. Otherwise,
22 Handler triggers no market-related events due to absense of
23 a source for those events.
25 Market data replay can be done with the help of the
26 OnixS::CME::MDH::Handler::replay member. It accepts
27 an instance of OnixS::CME::MDH::ReplaySettings class
28 containing a list of logs for replay.
30 A collection of log files to replay can be either assigned
31 manually or fulfilled using utility routines provided by the
32 SDK if log files were recorded using standard naming conventions
33 used by the SDK and the OnixS::CME::MDH::FileLogger in particular.
37 ReplaySettings replaySettings;
39 // Collects all log files recorded for
40 // channel 310 and stored in logStore folder.
43 replaySettings.logs(),
47 handler.replay(replaySettings);
51 Alternatively, it is possible to define a list of log files manually.
52 A manually manipulated list of log files allows replaying log files
53 which names differ from the names used by the Handler.
57 ReplaySettings replaySettings;
59 replaySettings.logs().push_back("1.txt");
60 replaySettings.logs().push_back("2.txt");
61 replaySettings.logs().push_back("3.txt");
65 \note Files to be replayed must be in exact order as they were
66 recorded by the Handler in bounds of a single processing session.
68 \note In contrast to the previous major versions, the Handler
69 performs a log file replay synchronously. As a result, the
70 OnixS::CME::MDH::Handler::replay does not return the control
71 to the caller unless entire data is replayed. The given approach
72 simplifies detection of the end of the replay.
74 From the event invocation perspective, there's no difference whether
75 the Handler processes market received by the network or from a log file.
77 \note In case of live market data processing, the Handler raises events
78 that reflect processing results as soon as market data is received from
79 the network and processed. However, the MDP spreads market data with different
80 frequency, which depends on live market activity. Therefore, there're delays
81 of different duration between triggered events. When the Handler replays
82 a log file, it does not do any pauses between data items, and thus,
83 it raises corresponding events as soon as data is retrieved from that
86 During the replay, the OnixS::CME::MDH::PacketArgs::receiveTime member
87 returns original time when market data packet was obtained from the network.
89 \note Currently, log replay must be run with the same set of the
90 Handler's settings which were originally used.
92 A sample application demonstrating a Log Replay feature can be found
93 in the samples/LogReplay subfolder of the SDK distributive package.
