timely/dataflow/operators/capture/replay.rs
1//! Traits and types for replaying captured timely dataflow streams.
2//!
3//! A type can be replayed into any timely dataflow scope if it presents as an
4//! iterator whose `Item` type implements `EventIterator` with the same timestamp.
5//! Other types can implement the `ReplayInto` trait, but this should be done with
6//! care, as there is a protocol the replayer follows that must be respected if the
7//! computation is to make sense.
8//!
9//! # Protocol
10//!
11//! The stream of events produced by each `EventIterator` implementation must satisfy,
12//! starting from a default timestamp of `Timestamp::minimum()` with count 1,
13//!
14//! 1. The progress messages may only increment the count for a timestamp if
15//! the cumulative count for some prior or equal timestamp is positive.
16//! 2. The data messages map only use a timestamp if the cumulative count for
17//! some prior or equal timestamp is positive.
18//!
19//! Alternately, the sequence of events should, starting from an initial count of 1
20//! for the timestamp `Default::default()`, describe decrements to held capabilities
21//! or the production of capabilities in their future, or messages sent at times in
22//! the future of held capabilities.
23//!
24//! The order is very important here. One can move `Event::Message` events arbitrarily
25//! earlier in the sequence, and `Event::Progress` events arbitrarily later, but one
26//! cannot move a `Event::Progress` message that discards a last capability before any
27//! `Event::Message` that would use that capability.
28//!
29//! For an example, the `Operate<T>` implementation for `capture::CaptureOperator<T, D, P>`
30//! records exactly what data is presented at the operator, both in terms of progress
31//! messages and data received.
32//!
33//! # Notes
34//!
35//! Provided no stream of events reports the consumption of capabilities it does not hold,
36//! any interleaving of the streams of events will still maintain the invariants above.
37//! This means that each timely dataflow replay operator can replay any number of streams,
38//! allowing the replay to occur in a timely dataflow computation with more or fewer workers
39//! than that in which the stream was captured.
40
41use crate::dataflow::{Scope, StreamCore};
42use crate::dataflow::channels::pushers::CounterCore as PushCounter;
43use crate::dataflow::channels::pushers::buffer::BufferCore as PushBuffer;
44use crate::dataflow::operators::generic::builder_raw::OperatorBuilder;
45use crate::progress::Timestamp;
46
47use super::EventCore;
48use super::event::EventIteratorCore;
49use crate::Container;
50
51/// Replay a capture stream into a scope with the same timestamp.
52pub trait Replay<T: Timestamp, C> : Sized {
53 /// Replays `self` into the provided scope, as a `Stream<S, D>`.
54 fn replay_into<S: Scope<Timestamp=T>>(self, scope: &mut S) -> StreamCore<S, C> {
55 self.replay_core(scope, Some(std::time::Duration::new(0, 0)))
56 }
57 /// Replays `self` into the provided scope, as a `Stream<S, D>'.
58 ///
59 /// The `period` argument allows the specification of a re-activation period, where the operator
60 /// will re-activate itself every so often. The `None` argument instructs the operator not to
61 /// re-activate itself.us
62 fn replay_core<S: Scope<Timestamp=T>>(self, scope: &mut S, period: Option<std::time::Duration>) -> StreamCore<S, C>;
63}
64
65impl<T: Timestamp, C: Container, I> Replay<T, C> for I
66where I : IntoIterator,
67 <I as IntoIterator>::Item: EventIteratorCore<T, C>+'static {
68 fn replay_core<S: Scope<Timestamp=T>>(self, scope: &mut S, period: Option<std::time::Duration>) -> StreamCore<S, C>{
69
70 let mut builder = OperatorBuilder::new("Replay".to_owned(), scope.clone());
71
72 let address = builder.operator_info().address;
73 let activator = scope.activator_for(&address[..]);
74
75 let (targets, stream) = builder.new_output();
76
77 let mut output = PushBuffer::new(PushCounter::new(targets));
78 let mut event_streams = self.into_iter().collect::<Vec<_>>();
79 let mut started = false;
80 let mut allocation: C = Default::default();
81
82 builder.build(
83 move |progress| {
84
85 if !started {
86 // The first thing we do is modify our capabilities to match the number of streams we manage.
87 // This should be a simple change of `self.event_streams.len() - 1`. We only do this once, as
88 // our very first action.
89 progress.internals[0].update(S::Timestamp::minimum(), (event_streams.len() as i64) - 1);
90 started = true;
91 }
92
93 for event_stream in event_streams.iter_mut() {
94 while let Some(event) = event_stream.next() {
95 match event {
96 EventCore::Progress(vec) => {
97 progress.internals[0].extend(vec.iter().cloned());
98 },
99 EventCore::Messages(ref time, data) => {
100 allocation.clone_from(data);
101 output.session(time).give_container(&mut allocation);
102 }
103 }
104 }
105 }
106
107 // A `None` period indicates that we do not re-activate here.
108 if let Some(delay) = period {
109 activator.activate_after(delay);
110 }
111
112 output.cease();
113 output.inner().produced().borrow_mut().drain_into(&mut progress.produceds[0]);
114
115 false
116 }
117 );
118
119 stream
120 }
121}