MongoJournal

Plugin API: asynchronously deletes all persistent messages up to toSequenceNr (inclusive).

Plugin API: asynchronously reads the highest stored sequence number for the given processorId.

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

The replayCallback must also be called with messages that have been marked as deleted. In this case a replayed message's deleted method must return true.

The channel ids of delivery confirmations that are available for a replayed message must be contained in that message's confirms sequence.

Plugin API: asynchronously writes a batch (Seq) of persistent messages to the journal.

The batch is only for performance reasons, i.e. all messages don't have to be written atomically. Higher throughput can typically be achieved by using batch inserts of many records compared inserting records one-by-one, but this aspect depends on the underlying data store and a journal implementation can implement it as efficient as possible with the assumption that the messages of the batch are unrelated.

Each AtomicWrite message contains the single PersistentRepr that corresponds to the event that was passed to the persist method of the PersistentActor, or it contains several PersistentRepr that corresponds to the events that were passed to the persistAll method of the PersistentActor. All PersistentRepr of the AtomicWrite must be written to the data store atomically, i.e. all or none must be stored. If the journal (data store) cannot support atomic writes of multiple events it should reject such writes with a Try Failure with an UnsupportedOperationException describing the issue. This limitation should also be documented by the journal plugin.

If there are failures when storing any of the messages in the batch the returned Future must be completed with failure. The Future must only be completed with success when all messages in the batch have been confirmed to be stored successfully, i.e. they will be readable, and visible, in a subsequent replay. If there is uncertainty about if the messages were stored or not the Future must be completed with failure.

Data store connection problems must be signaled by completing the Future with failure.

The journal can also signal that it rejects individual messages (AtomicWrite) by the returned immutable.Seq[Try[Unit]]. The returned Seq must have as many elements as the input messages Seq. Each Try element signals if the corresponding AtomicWrite is rejected or not, with an exception describing the problem. Rejecting a message means it was not stored, i.e. it must not be included in a later replay. Rejecting a message is typically done before attempting to store it, e.g. because of serialization error.

Data store connection problems must not be signaled as rejections.

Note that it is possible to reduce number of allocations by caching some result Seq for the happy path, i.e. when no messages are rejected.

Plugin API

Allows plugin implementers to use f pipeTo self and handle additional messages for implementing advanced features

User overridable callback: By default it calls preStart().

User overridable callback.

Is called asynchronously after 'actor.stop()' is invoked. Empty default implementation.

Scala API: User overridable callback: '''By default it disposes of all children and then calls postStop().'''

User overridable callback.

Is called when an Actor is started. Actors are automatically started asynchronously when created. Empty default implementation.

Scala API: This defines the initial actor behavior, it must return a partial function with the actor logic.

The reference sender Actor of the last received message. Is defined if the message was sent from another Actor, else deadLetters in pekko.actor.ActorSystem.

WARNING: Only valid within the Actor itself, so do not close over it and publish it to other threads!

User overridable definition the strategy to use for supervising child actors.

User overridable callback.

Is called when a message isn't handled by the current behavior of the actor by default it fails with either a pekko.actor.DeathPactException (in case of an unhandled pekko.actor.Terminated message) or publishes an pekko.actor.UnhandledMessage to the actor's system's pekko.event.EventStream

Scala API: Stores the context for this actor, including self, and sender. It is implicit to support operations such as forward.

WARNING: Only valid within the Actor itself, so do not close over it and publish it to other threads!

pekko.actor.ActorContext is the Scala API. getContext returns a pekko.actor.AbstractActor.ActorContext, which is the Java API of the actor context.

The 'self' field holds the ActorRef for this actor.

Can be used to send messages to itself:

self ! message