Can be overridden to intercept calls to postRestart
.
Can be overridden to intercept calls to postStop
.
Can be overridden to intercept calls to preRestart
.
Can be overridden to intercept calls to preStart
.
INTERNAL API.
Plugin API: asynchronously deletes all persistent messages up to toSequenceNr
(inclusive).
Plugin API: asynchronously deletes all persistent messages up to toSequenceNr
(inclusive).
This call is protected with a circuit-breaker.
Plugin API: asynchronously reads the highest stored sequence number for the
given persistenceId
.
Plugin API: asynchronously reads the highest stored sequence number for the
given persistenceId
. The persistent actor will use the highest sequence
number after recovery as the starting point when persisting new events.
This sequence number is also used as toSequenceNr
in subsequent call
to #asyncReplayMessages unless the user has specified a lower toSequenceNr
.
This call is protected with a circuit-breaker.
persistent actor id.
hint where to start searching for the highest sequence
number. When a persistent actor is recovering this
fromSequenceNr
will be the sequence number of the used
snapshot or 0L
if no snapshot is used.
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
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 toSequenceNr
is the lowest of what was returned by #asyncReadHighestSequenceNr
and what the user specified as recovery akka.persistence.Recovery parameter.
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.
persistent actor id.
sequence number where replay should start (inclusive).
sequence number where replay should end (inclusive).
maximum number of messages to be replayed.
Plugin API: asynchronously writes a batch (Seq
) of persistent messages to the
journal.
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 to 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. Journals should aim to persist events in-order for a given persistenceId
as otherwise in case of a failure, the persistent state may be end up being inconsistent.
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]]
. It is possible but not mandatory to reduce
number of allocations by returning Future.successful(Nil)
for the happy path,
i.e. when no messages are rejected. Otherwise 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.
It is possible but not mandatory to reduce number of allocations by returning
Future.successful(Nil)
for the happy path, i.e. when no messages are rejected.
This call is protected with a circuit-breaker.
Stores the context for this actor, including self, and sender.
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!
akka.actor.ActorContext is the Scala API. getContext
returns a
akka.actor.UntypedActorContext, which is the Java API of the actor
context.
User overridable callback: By default it calls preStart()
.
User overridable callback: By default it calls preStart()
.
the Throwable that caused the restart to happen Is called right AFTER restart on the newly created Actor to allow reinitialization after an Actor crash.
User overridable callback.
User overridable callback.
Is called asynchronously after 'actor.stop()' is invoked. Empty default implementation.
User overridable callback: By default it disposes of all children and then calls postStop()
.
User overridable callback: By default it disposes of all children and then calls postStop()
.
the Throwable that caused the restart to happen
optionally the current message the actor processed when failing, if applicable Is called on a crashed Actor right BEFORE it is restarted to allow clean up of resources before Actor is terminated.
User overridable callback.
User overridable callback.
Is called when an Actor is started. Actors are automatically started asynchronously when created. Empty default implementation.
This defines the initial actor behavior, it must return a partial function with the actor logic.
This defines the initial actor behavior, it must return a partial function with the actor logic.
Plugin API
Plugin API
Allows plugin implementers to use f pipeTo self
and
handle additional messages for implementing advanced features
The 'self' field holds the ActorRef for this actor.
The 'self' field holds the ActorRef for this actor.
Can be used to send messages to itself:
self ! message
The reference sender Actor of the last received message.
The reference sender Actor of the last received message.
Is defined if the message was sent from another Actor,
else deadLetters
in akka.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 definition the strategy to use for supervising child actors.
User overridable callback.
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 akka.actor.DeathPactException (in case of an unhandled akka.actor.Terminated message) or publishes an akka.actor.UnhandledMessage to the actor's system's akka.event.EventStream
Java API: abstract journal, optimized for asynchronous, non-blocking writes.