org.apache.pekko.persistence.fsm

Java API: compatible with lambda expressions

Persistent Finite State Machine actor abstract base class.

Java API: compatible with lambda expressions

Java API: compatible with lambda expressions

Finite State Machine actor abstract base class.

Java API: compatible with lambda expressions

Persistent Finite State Machine actor abstract base class with FSM Logging

Stackable trait for pekko.actor.FSM which adds a rolling event log and debug logging capabilities (analogous to pekko.event.LoggingReceive).

A FSM implementation with persistent state.

Supports the usual pekko.actor.FSM functionality with additional persistence features. PersistentFSM is identified by 'persistenceId' value. State changes are persisted atomically together with domain events, which means that either both succeed or both fail, i.e. a state transition event will not be stored if persistence of an event related to that change fails. Persistence execution order is: persist -> wait for ack -> apply state. Incoming messages are deferred until the state is applied. State Data is constructed based on domain events, according to user's implementation of applyEvent function.

Finite State Machine actor trait. Use as follows:

 object A {
   trait State
   case class One extends State
   case class Two extends State

   case class Data(i : Int)
 }

 class A extends Actor with FSM[A.State, A.Data] {
   import A._

   startWith(One, Data(42))
   when(One) {
       case Event(SomeMsg, Data(x)) => ...
       case Event(SomeOtherMsg, _) => ... // convenience when data not needed
   }
   when(Two, stateTimeout = 5 seconds) { ... }
   initialize()
 }

Within the partial function the following values are returned for effecting state transitions:

• stay for staying in the same state
• stay using Data(...) for staying in the same state, but with different data
• stay forMax 5.millis for staying with a state timeout; can be combined with using
• goto(...) for changing into a different state; also supports using and forMax
• stop for terminating this FSM actor

Each of the above also supports the method replying(AnyRef) for sending a reply before changing state.

While changing state, custom handlers may be invoked which are registered using onTransition. This is meant to enable concentrating different concerns in different places; you may choose to use when for describing the properties of a state, including of course initiating transitions, but you can describe the transitions using onTransition to avoid having to duplicate that code among multiple paths which lead to a transition:

onTransition {
 case Active -> _ => cancelTimer("activeTimer")
}

Multiple such blocks are supported and all of them will be called, not only the first matching one.

Another feature is that other actors may subscribe for transition events by sending a SubscribeTransitionCallback message to this actor. Stopping a listener without unregistering will not remove the listener from the subscription list; use UnsubscribeTransitionCallback before stopping the listener.

State timeouts set an upper bound to the time which may pass before another message is received in the current state. If no external message is available, then upon expiry of the timeout a StateTimeout message is sent. Note that this message will only be received in the state for which the timeout was set and that any message received will cancel the timeout (possibly to be started again by the next transition).

Another feature is the ability to install and cancel single-shot as well as repeated timers which arrange for the sending of a user-specified message:

 startTimerWithFixedDelay("tock", TockMsg, 1 second) // repeating
 startSingleTimer("lifetime", TerminateMsg, 1 hour) // single-shot
 cancelTimer("tock")
 isTimerActive("tock")