Class MimicReplayProtocol
EventBus in (scaled) real time, exercising the normal,
non-interop data path: each decoded sample is published as a parsed DataPoint message on
an address of the shape "<className>.<deviceID>.<channelID>.parsed", exactly as the live
device drivers do. Downstream writers, dispatchers and CDSS reactors therefore see the record as
if it came from a real monitor.
WFDB records are read directly (no external tooling): the master multi-segment header defines
segment order and gaps, each segment header supplies the per-signal format, gain, baseline, units
and name, and WfdbSegmentReader decodes the .dat payload. Gap ("~") and
zero-length layout segments are skipped without stalling the replay clock, so the emitted stream
is continuous. Signal names from the header become channel IDs (e.g. II, PLETH,
ABP); values are converted to physical units, or passed through raw for uncalibrated
signals.
Configuration keys
recordPath— path to the record's master.heaheader file.deviceID— device identifier stamped on every sample (sinks bind to this).className— semantic category used as the address prefix (e.g.Waveform).channels— JSON array of signal names to replay; empty replays all signals.speed— replay-speed multiplier (1.0= real time,60= 60×).maxSeconds— stop after this much record time (0= whole record).
Replay runs on a dedicated daemon-style thread started from connect(); the samples are
paced against wall-clock time so trend/window reactors observe realistic timing. When the record
is exhausted onReplayComplete() is invoked (by default it drains briefly and terminates
the JVM, matching the CSV/JSONL replay driver).
Pacing statistics
Replay always accumulates cheap per-frame pacing statistics — how far each frame's actual
emit time drifted from its scheduled time — and logs a one-line summary just before
onReplayComplete(). The same figures are available programmatically via
pacingStats(); together they answer whether the deployment sustains the record's sampling
frequency. See MimicReplayProtocol.PacingStats for the threading contract.
-
Nested Class Summary
Nested ClassesModifier and TypeClassDescriptionstatic final recordImmutable summary of how closely replay followed its schedule. -
Field Summary
Fields inherited from class com.framed.core.Service
ADDRESS_REGISTRY_SUFFIX, eventBus, formatter, logger -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidconnect()Establishes a connection using the specific protocol implementation and starts the configured data export.protected voidInvoked once the whole record (ormaxSecondsof it) has been replayed.Returns a snapshot of the replay's pacing fidelity — how well the producer held the configured sample rate.protected longMilliseconds to wait after construction before replay begins, giving sinks and reactors time to be instantiated and to subscribe.Methods inherited from class com.framed.core.Service
addressRegistry, announceAddress, stop, subscribeToAnnouncements
-
Constructor Details
-
MimicReplayProtocol
public MimicReplayProtocol(String id, EventBus eventBus, String recordPath, String deviceID, String className, org.json.JSONArray channels, double speed, double maxSeconds) Creates a MIMIC replay protocol. Parameter names match the JSON configuration keys resolved byFactory; theEventBusis injected automatically.- Parameters:
id- unique service identifiereventBus- the event bus samples are published onrecordPath- path to the record's master.heaheader filedeviceID- device identifier stamped on every emitted sampleclassName- semantic category used as the address prefixchannels- signal names to replay; empty (or[ ]) replays every signalspeed- replay-speed multiplier (1.0= real time)maxSeconds- stop after this much record time in seconds;0replays the whole record
-
-
Method Details
-
connect
public void connect()Description copied from class:ProtocolEstablishes a connection using the specific protocol implementation and starts the configured data export. Concrete subclasses must provide the logic for connecting. -
startupDelayMillis
protected long startupDelayMillis()Milliseconds to wait after construction before replay begins, giving sinks and reactors time to be instantiated and to subscribe. Overridable for tests.- Returns:
- the startup delay in milliseconds
-
onReplayComplete
protected void onReplayComplete()Invoked once the whole record (ormaxSecondsof it) has been replayed. The default drains briefly to let downstream processing finish and then terminates the JVM, matching the CSV/JSONL replay driver's behaviour. Tests override this to avoid exiting. -
pacingStats
Returns a snapshot of the replay's pacing fidelity — how well the producer held the configured sample rate.Threading: the underlying counters are written only by the replay thread. A caller on another thread sees a consistent, final snapshot once it has observed replay completion through a happens-before edge (e.g. a latch counted down from an overridden
onReplayComplete()). Reading it during replay yields a torn but order-of-magnitude-correct view.- Returns:
- the pacing statistics accumulated so far
-
