public abstract class AsyncWriteJournal extends AsyncRecovery implements AsyncWriteJournal
AsyncWriteJournal.Desequenced, AsyncWriteJournal.Desequenced$, AsyncWriteJournal.Resequencer
Constructor and Description |
---|
AsyncWriteJournal() |
Modifier and Type | Method and Description |
---|---|
scala.concurrent.Future<scala.runtime.BoxedUnit> |
asyncDeleteMessagesTo(java.lang.String persistenceId,
long toSequenceNr)
Plugin API: asynchronously deletes all persistent messages up to
toSequenceNr
(inclusive). |
scala.concurrent.Future<scala.collection.immutable.Seq<scala.util.Try<scala.runtime.BoxedUnit>>> |
asyncWriteMessages(scala.collection.immutable.Seq<AtomicWrite> messages)
Plugin API: asynchronously writes a batch (
Seq ) of persistent messages to the
journal. |
scala.concurrent.Future<java.lang.Void> |
doAsyncDeleteMessagesTo(java.lang.String persistenceId,
long toSequenceNr)
Java API, Plugin API: synchronously deletes all persistent messages up to
`toSequenceNr`.
|
scala.concurrent.Future<java.lang.Long> |
doAsyncReadHighestSequenceNr(java.lang.String persistenceId,
long fromSequenceNr)
Java API, Plugin API: asynchronously reads the highest stored sequence
number for the given `persistenceId`.
|
scala.concurrent.Future<java.lang.Void> |
doAsyncReplayMessages(java.lang.String persistenceId,
long fromSequenceNr,
long toSequenceNr,
long max,
java.util.function.Consumer<PersistentRepr> replayCallback)
Java API, Plugin API: asynchronously replays persistent messages.
|
scala.concurrent.Future<java.lang.Iterable<java.util.Optional<java.lang.Exception>>> |
doAsyncWriteMessages(java.lang.Iterable<AtomicWrite> messages)
Java API, Plugin API: asynchronously writes a batch (`Iterable`) of
persistent messages to the journal.
|
asyncReadHighestSequenceNr, asyncReplayMessages
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
breaker, config, extension, isReplayFilterEnabled, publish, receive, receivePluginInternal, receiveWriteJournal, replayFilterMaxOldWriters, replayFilterMode, replayFilterWindowSize, resequencer, resequencerCounter
akka$actor$Actor$_setter_$context_$eq, akka$actor$Actor$_setter_$self_$eq, aroundPostRestart, aroundPostStop, aroundPreRestart, aroundPreStart, aroundReceive, context, postRestart, postStop, preRestart, preStart, self, sender, supervisorStrategy, unhandled
adaptFromJournal, adaptToJournal, eventAdapters, persistence, preparePersistentBatch
asyncReadHighestSequenceNr, asyncReplayMessages
public final scala.concurrent.Future<scala.collection.immutable.Seq<scala.util.Try<scala.runtime.BoxedUnit>>> asyncWriteMessages(scala.collection.immutable.Seq<AtomicWrite> messages)
AsyncWriteJournal
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.
asyncWriteMessages
in interface AsyncWriteJournal
messages
- (undocumented)public final scala.concurrent.Future<scala.runtime.BoxedUnit> asyncDeleteMessagesTo(java.lang.String persistenceId, long toSequenceNr)
AsyncWriteJournal
toSequenceNr
(inclusive).
This call is protected with a circuit-breaker.
asyncDeleteMessagesTo
in interface AsyncWriteJournal
persistenceId
- (undocumented)toSequenceNr
- (undocumented)public scala.concurrent.Future<java.lang.Iterable<java.util.Optional<java.lang.Exception>>> doAsyncWriteMessages(java.lang.Iterable<AtomicWrite> messages)
public scala.concurrent.Future<java.lang.Void> doAsyncDeleteMessagesTo(java.lang.String persistenceId, long toSequenceNr)
AsyncRecoveryPlugin
public scala.concurrent.Future<java.lang.Void> doAsyncReplayMessages(java.lang.String persistenceId, long fromSequenceNr, long toSequenceNr, long max, java.util.function.Consumer<PersistentRepr> replayCallback)
doAsyncReadHighestSequenceNr(java.lang.String, long)
and what the user specified as
recovery Recovery
parameter.persistenceId
- id of the persistent actor.fromSequenceNr
- sequence number where replay should start (inclusive).toSequenceNr
- sequence number where replay should end (inclusive).max
- maximum number of messages to be replayed.replayCallback
- called to replay a single message. Can be called from any thread.public scala.concurrent.Future<java.lang.Long> doAsyncReadHighestSequenceNr(java.lang.String persistenceId, long fromSequenceNr)
persistenceId
- id of the persistent actor.fromSequenceNr
- hint where to start searching for the highest sequence number.