Module io.smallrye.mutiny
Package io.smallrye.mutiny.groups

Class MultiReplay

java.lang.Object
io.smallrye.mutiny.groups.MultiReplay
public class MultiReplay extends Object
Group to configure replaying a Multi to multiple subscribers.

  • Constructor Details

    • MultiReplay

      public MultiReplay()

  • Method Details

    • upTo

      @CheckReturnValue 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

      @CheckReturnValue 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 Flow.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

      @CheckReturnValue public <T> Multi<T> ofSeedAndMulti(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: