Multi is a cold-source: no processing happens until you subscribe.
broadcast operator can be used so that multiple subscribers consume a
Multi events at the same time, it does not support replaying items for late subscribers: when a subscriber joins after the
Multi has completed (or failed), then it won’t receive any item.
This is where replaying can be useful.
Replaying all events#
Replaying all events from an upstream
Multi works as follows:
item_2 trigger new subscriptions, and both lists contain the following elements:
Replaying works by turning
upstream into a hot-stream, meaning that it gets requested
This is done when the first subscription happens.
The replay operator stores the items in an internal replay log, and then each subscriber gets to replay them.
Subscribers demand and cancellation requests are honored while replaying, but
upstream cannot be cancelled.
Be careful with unbounded streams as you can exhaust memory!
In such cases or when you need to replay large amounts of data, you might opt to use some eventing middleware rather than Mutiny replays.
Replaying the last ‘n’ events#
You can limit the number of elements to replay by using the
Each new subscriber gets to replay the last
n elements from where the replay log is at subscription time.
For instance the first subscriber can observe all events, while a subscriber that joins 2 seconds later might not observe the earlier events.
Multi.createFrom().range(0, 10) is an immediate stream, both
item_2 lists contain the last items:
Prepending with seed data#
In some cases you might want to prepend some seed data that will be available for replay before the upstream starts emitting.
You can do so using an
Iterable to provide such seed data:
In which case subscribers can observe the following events:
Replay of failures and completions#
Subscribers get to observe not just items but also the failure and completion events:
Running this code yields the following output for any subscriber: