Click or drag to resize
Akka.NETAsyncWriteJournal Class
Abstract journal, optimized for asynchronous, non-blocking writes.
Inheritance Hierarchy

Namespace:  Akka.Persistence.Journal
Assembly:  Akka.Persistence (in Akka.Persistence.dll) Version: 1.2.3.42 (1.2.3.42)
Syntax
public abstract class AsyncWriteJournal : WriteJournalBase, 
	IAsyncRecovery

The AsyncWriteJournal type exposes the following members.

Constructors
  NameDescription
Protected methodAsyncWriteJournal
Initializes a new instance of the AsyncWriteJournal class.
Top
Properties
  NameDescription
Protected propertySelf
Gets the self ActorRef
(Inherited from ActorBase.)
Protected propertySender
Gets the sending ActorRef of the current message
(Inherited from ActorBase.)
Top
Methods
  NameDescription
Protected methodAdaptFromJournal
TBD
(Inherited from WriteJournalBase.)
Protected methodAdaptToJournal
TBD
(Inherited from WriteJournalBase.)
Public methodAroundPostRestart
Can be overridden to intercept calls to `PostRestart`. Calls `PostRestart` by default.
(Inherited from ActorBase.)
Public methodAroundPostStop
Can be overridden to intercept calls to `PostStop`. Calls `PostStop` by default..
(Inherited from ActorBase.)
Public methodAroundPreRestart
Can be overridden to intercept calls to `PreRestart`. Calls `PreRestart` by default.
(Inherited from ActorBase.)
Public methodAroundPreStart
Can be overridden to intercept calls to `PreStart`. Calls `PreStart` by default.
(Inherited from ActorBase.)
Protected methodAroundReceive
TBD
(Inherited from ActorBase.)
Protected methodBecome
Changes the actor's command behavior and replaces the current receive handler with the specified handler.
(Inherited from ActorBase.)
Protected methodBecomeStacked
Changes the actor's behavior and replaces the current receive handler with the specified handler. The current handler is stored on a stack, and you can revert to it by calling UnbecomeStacked
Remarks
Please note, that in order to not leak memory, make sure every call to BecomeStacked(Receive) is matched with a call to UnbecomeStacked.
(Inherited from ActorBase.)
Protected methodDeleteMessagesToAsync
Asynchronously deletes all persistent messages up to inclusive toSequenceNr bound.
Public methodEquals
Determines whether the specified object is equal to the current object.
(Inherited from Object.)
Protected methodFinalize
Allows an object to try to free resources and perform other cleanup operations before it is reclaimed by garbage collection.
(Inherited from Object.)
Public methodGetHashCode
Serves as the default hash function.
(Inherited from Object.)
Public methodGetType
Gets the Type of the current instance.
(Inherited from Object.)
Protected methodMemberwiseClone
Creates a shallow copy of the current Object.
(Inherited from Object.)
Protected methodPostRestart
User overridable callback: By default it calls `PreStart()`.

Is called right AFTER restart on the newly created Actor to allow reinitialization after an Actor crash.

(Inherited from ActorBase.)
Protected methodPostStop
User overridable callback.

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

(Inherited from ActorBase.)
Protected methodPreparePersistentBatch
TBD
(Inherited from WriteJournalBase.)
Protected methodPreRestart
User overridable callback: '''By default it disposes of all children and then calls `postStop()`.'''

Is called on a crashed Actor right BEFORE it is restarted to allow clean up of resources before Actor is terminated.

(Inherited from ActorBase.)
Protected methodPreStart
User overridable callback.

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

(Inherited from ActorBase.)
Public methodReadHighestSequenceNrAsync
Asynchronously reads the highest stored sequence number for provided 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 calls to ReplayMessagesAsync(IActorContext, String, Int64, Int64, Int64, ActionIPersistentRepresentation) unless the user has specified a lower `toSequenceNr`. Journal must maintain the highest sequence number and never decrease it. This call is protected with a circuit-breaker. Please also not that requests for the highest sequence number 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.
Protected methodReceive
Processor for user defined messages.
(Overrides ActorBaseReceive(Object).)
Protected methodReceivePluginInternal
Protected methodReceiveWriteJournal
TBD
Public methodReplayMessagesAsync
Asynchronously replays persistent messages. Implementations replay a message by calling recoveryCallback. The returned task must be completed when all messages (matching the sequence number bounds) have been replayed. The task must be completed with a failure if any of the persistent messages could not be replayed. The toSequenceNr is the lowest of what was returned by ReadHighestSequenceNrAsync(String, Int64) and what the user specified as recovery Recovery parameter. This does imply that this call is always preceded by reading the highest sequence number for the given persistenceId. This call is NOT protected with a circuit-breaker because it may take a long time to replay all events. The plugin implementation itself must protect against an unresponsive backend store and make sure that the returned Task is completed with success or failure within reasonable time. It is not allowed to ignore completing the Task.
Protected methodSetReceiveTimeout

Defines the inactivity timeout after which the sending of a ReceiveTimeout message is triggered. When specified, the receive function should be able to handle a ReceiveTimeout message.

Please note that the receive timeout might fire and enqueue the ReceiveTimeout message right after another message was enqueued; hence it is not guaranteed that upon reception of the receive timeout there must have been an idle period beforehand as configured via this method.

Once set, the receive timeout stays in effect (i.e. continues firing repeatedly after inactivity periods). Pass in null to switch off this feature.

(Inherited from ActorBase.)
Protected methodSupervisorStrategy
TBD
(Inherited from ActorBase.)
Public methodToString
Returns a string that represents the current object.
(Inherited from Object.)
Protected methodTryUnwrapException
TBD
Protected methodUnbecomeStacked
Reverts the Actor behavior to the previous one on the behavior stack.
(Inherited from ActorBase.)
Protected methodUnhandled
Is called when a message isn't handled by the current behavior of the actor by default it fails with either a DeathPactException (in case of an unhandled Terminated message) or publishes an UnhandledMessage to the actor's system's EventStream
(Inherited from ActorBase.)
Protected methodWriteMessagesAsync
Plugin API: asynchronously writes a batch 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 Persistent that corresponds to the event that was passed to the PersistTEvent(TEvent, ActionTEvent) method of the PersistentActor, or it contains several Persistent that correspond to the events that were passed to the PersistAllTEvent(IEnumerableTEvent, ActionTEvent) method of the PersistentActor. All Persistent 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 NotSupportedException 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 Task must be completed with failure. The Task 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 Task must be completed with failure. Data store connection problems must be signaled by completing the Task with failure. The journal can also signal that it rejects individual messages (AtomicWrite) by the returned Task. It is possible but not mandatory to reduce number of allocations by returning null for the happy path, i.e. when no messages are rejected. Otherwise the returned list must have as many elements as the input messages. Each result 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 null for the happy path, i.e. when no messages are rejected. Calls to this method are serialized by the enclosing journal actor. If you spawn work in asynchronous tasks it is alright that they complete the futures in any order, but the actual writes for a specific persistenceId should be serialized to avoid issues such as events of a later write are visible to consumers (query side, or replay) before the events of an earlier write are visible. A PersistentActor will not send a new WriteMessages request before the previous one has been completed. Please not that the Sender of the contained Persistent objects has been nulled out (i.e. set to NoSender in order to not use space in the journal for a sender reference that will likely be obsolete during replay. Please also note that requests for the highest sequence number may be made concurrently to this call executing for the same `persistenceId`, in particular it is possible that a restarting actor tries to recover before its outstanding writes have completed. In the latter case it is highly desirable to defer reading the highest sequence number until all outstanding writes have completed, otherwise the PersistentActor may reuse sequence numbers. This call is protected with a circuit-breaker.
Top
Fields
  NameDescription
Protected fieldCanPublish
Top
Extension Methods
See Also