This tutorial contains examples that illustrate a subset of Akka Persistence features.
Custom storage locations for the journal and snapshots can be defined in application.conf.
ProcessorChannelExample.java
defines an ExampleProcessor and an ExampleDestination. The processor sends messages to a
destination via a channel. The destination confirms the delivery of these messages so that replayed messages aren't
redundantly delivered to the destination. Repeated runs of the application demonstrates that the processor receives
both replayed and new messages whereas the channel only receives new messages, sent by the application. The processor
also receives replies from the destination, demonstrating that a channel preserves sender references.
To run this example, go to the Run tab, and run the application main class
sample.persistence.ProcessorChannelExample several times.
SnapshotExample.java demonstrates how processors can take snapshots of application state and recover from previously stored snapshots. Snapshots are offered to processors at the beginning of recovery, before any messages (younger than the snapshot) are replayed.
To run this example, go to the Run tab, and run the application main class
sample.persistence.SnapshotExample several times. With every run, the state offered by the
most recent snapshot is printed to stdout, followed by the updated state after sending new persistent
messages to the processor.
EventsourcedExample.java
is described in detail in the Event sourcing
section of the user documentation. With every application run, the ExampleProcessor is recovered from
events stored in previous application runs, processes new commands, stores new events and snapshots and prints the
current processor state to stdout.
To run this example, go to the Run tab, and run the application main class
sample.persistence.EventsourcedExample several times.
ProcessorFailureExample.java
shows how a processor can delete persistent messages from the journal if they threw an exception. Throwing an exception
restarts the processor and replays messages. In order to prevent that the message that caused the exception is replayed,
it is marked as deleted in the journal (during invocation of preRestart). This is a common pattern in
command-sourcing to compensate write-ahead logging of messages.
To run this example, go to the Run tab, and run the application main class
sample.persistence.ProcessorFailureExample several times.
Event sourcing on the other hand, does not persist commands directly but rather events that have been derived from received commands (not shown here). These events are known to be successfully applicable to current processor state i.e. there's no need for deleting them from the journal. Event sourced processors usually have a lower throughput than command sourced processors, as the maximum size of a write batch is limited by the number of persisted events per received command.
ViewExample.java demonstrates
how a view (ExampleView) is updated with the persistent message stream of a processor
(ExampleProcessor). Messages sent to the processor are read from stdin. Views also support
snapshotting and can be used in combination with channels in the same way as processors.
To run this example, go to the Run tab, and run the application main class
sample.persistence.ViewExample.
Views can also receive events that have been persisted by event sourced processors (not shown).
ConversationRecoveryExample.java defines two processors that send messages to each other via channels. The reliable delivery properties of channels, in combination with processors, allow these processors to automatically resume their conversation after a JVM crash.
To run this example, go to the Run tab, and run the application main class
sample.persistence.ConversationRecoveryExample several times.