trait AsyncReplay extends AnyRef

A plugin may implement this trait as an optimization. Combining asyncReplayMessages and asyncReadHighestSequenceNr into one method. If this trait is implemented the methods in AsyncRecovery will not be called.

Source
AsyncRecovery.scala
Linear Supertypes
AnyRef, Any
Type Hierarchy
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. AsyncReplay
  2. AnyRef
  3. Any
Implicitly
  1. by any2stringadd
  2. by StringFormat
  3. by Ensuring
  4. by ArrowAssoc
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Abstract Value Members

  1. abstract def replayMessages(persistenceId: String, fromSequenceNr: Long, toSequenceNr: Long, max: Long)(recoveryCallback: (PersistentRepr) => Unit): Future[Long]

    Plugin API: asynchronously replays persistent messages.

    Plugin API: asynchronously replays persistent messages. Implementations replay a message by calling replayCallback. The returned future must be completed with the highest sequence number when all messages (matching the sequence number bounds) have been replayed. Journal must maintain the highest sequence number and never decrease it. The future must be completed with a failure if any of the persistent messages could not be replayed.

    The toSequenceNr will either be Long.MaxValue to replay all messages or otherwise a limited upper sequence number. When replaying all messages the returned highest sequence number should be the same as the last replayed message, and the implementation would typically not have to read highest sequence number in other way than replaying the messages. With a custom toSequenceNr the implementation would typically have to both replay messages and read the actual highest sequence number.

    One special case is toSequenceNr of 0, which means that no messages should be replayed, but the returned highest sequence number must still be the highest of all stored messages. In this case the implementation would typically have to read the actual highest sequence number but can skip replay of messages.

    Another special case is fromSequenceNr of -1, which means that only the last message if any should be replayed.

    This call is NOT protected with a circuit-breaker because it may take long time to replay all events. The plugin implementation itself must protect against an unresponsive backend store and make sure that the returned Future is completed with success or failure within reasonable time. It is not allowed to ignore completing the future.

    Please also note that requests to replayMessages may be made concurrently to writes executing for the same persistenceId, in particular it is possible that a restarting actor tries to recover before its outstanding writes have completed.

    persistenceId

    persistent actor id.

    fromSequenceNr

    sequence number where replay should start (inclusive).

    toSequenceNr

    sequence number where replay should end (inclusive).

    max

    maximum number of messages to be replayed.

    recoveryCallback

    called to replay a single message. Can be called from any thread.

    returns

    highest sequence number

    See also

    AsyncWriteJournal