Package io.smallrye.mutiny.groups

Class MultiReplay

  • @Experimental("Replaying of Multi is an experimental feature in Mutiny 1.4.0")
public class MultiReplay
extends java.lang.Object
    Group to configure replaying a Multi to multiple subscribers.

    • Constructor Summary

      Constructors 
      Constructor Description
      MultiReplay()  

    • Method Summary

      All Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      <T> Multi<T> ofMulti​(Multi<T> upstream)
      Create a replay Multi.
      <T> Multi<T> ofSeedAndMulti​(java.lang.Iterable<T> seed, Multi<T> upstream)
      Create a replay Multi with some seed elements inserted before the provided Multi items.
      MultiReplay upTo​(long numberOfItemsToReplay)
      Limit the number of items each new subscriber gets.

      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

    • Constructor Detail

      • MultiReplay

        public MultiReplay()

    • Method Detail

      • upTo

        public MultiReplay upTo​(long numberOfItemsToReplay)
        Limit the number of items each new subscriber gets. The default is to replay all events.
        Parameters:
        numberOfItemsToReplay - a strictly positive number of items to be replayed, where Long.MAX_VALUE means replaying all events
        Returns:
        this group

      • ofMulti

        public <T> Multi<T> ofMulti​(Multi<T> upstream)
        Create a replay Multi.

        Replaying work as follows.

        1. The provided upstream Multi is turned into a hot-stream as it gets requested Long.MAX_VALUE elements. This happens at the first subscription request. Note that upstream will never be cancelled.
        2. Each new subscriber to this replay Multi is able to replay items at its own pace (back-pressure is honored).
        3. When the number of items to replay is limited using upTo(long), then a new subscriber gets to replay starting from the current position in the upstream replay log. When the number of elements to replay is unbounded, then a new subscriber replays from the start.
        4. All current and late subscribers observe terminal completion / error signals.
        5. Items are pushed synchronously to subscribers when they call Subscription.request(long) and there are enough elements to satisfy a part of the demand. Otherwise items are pushed from the upstream to all subscribers with an outstanding demand.

        Replaying a large number of elements can be costly, as items have to be kept in-memory. It is NOT recommended using this operator with unbounded streams, especially as they can't be canceled (the subscribers can cancel replays, though). In such cases and especially when you have to keep replay data around for a long time then some eventing middleware might be a better fit.

        Type Parameters:
        T - the items type
        Parameters:
        upstream - the Multi to replay, must not be null
        Returns:
        a replaying Multi

      • ofSeedAndMulti

        public <T> Multi<T> ofSeedAndMulti​(java.lang.Iterable<T> seed,
                                   Multi<T> upstream)
        Create a replay Multi with some seed elements inserted before the provided Multi items.

        The behavior is that of ofMulti(Multi), except that the items from seed are prepended to those from upstream in the replay log.

        Type Parameters:
        T - the items type
        Parameters:
        seed - the seed elements, must not be null, must not contain any null element
        upstream - the Multi to replay, must not be null
        Returns:
        a replaying Multi
        See Also:
        ofMulti(Multi)