Type Members

1.  abstract class AbstractPersistentFSM [S <: FSMState, D, E] extends AbstractPersistentFSMBase[S, D, E] with PersistentFSM[S, D, E]

   Java API: compatible with lambda expressions

   Java API: compatible with lambda expressions

   Persistent Finite State Machine actor abstract base class.

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.

2.  abstract class AbstractPersistentFSMBase [S, D, E] extends PersistentFSMBase[S, D, E]

   Java API: compatible with lambda expressions

   Java API: compatible with lambda expressions

   Finite State Machine actor abstract base class.

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.

3.  abstract class AbstractPersistentLoggingFSM [S <: FSMState, D, E] extends AbstractPersistentFSMBase[S, D, E] with LoggingPersistentFSM[S, D, E] with PersistentFSM[S, D, E]

   Java API: compatible with lambda expressions

   Java API: compatible with lambda expressions

   Persistent Finite State Machine actor abstract base class with FSM Logging

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.

4.  trait LoggingPersistentFSM [S, D, E] extends PersistentFSMBase[S, D, E]

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

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

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.

5.  trait PersistentFSM [S <: FSMState, D, E] extends PersistentActor with PersistentFSMBase[S, D, E] with ActorLogging

   A FSM implementation with persistent state.

   A FSM implementation with persistent state.

   Supports the usual akka.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.

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.

6.  trait PersistentFSMBase [S, D, E] extends Actor with Listeners with ActorLogging

   Finite State Machine actor trait.

   Finite State Machine actor trait. Use as follows:

       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 Ev(SomeMsg) => ... // 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:

     setTimer("tock", TockMsg, 1 second, true) // repeating
     setTimer("lifetime", TerminateMsg, 1 hour, false) // single-shot
     cancelTimer("tock")
     isTimerActive("tock")
   

   This is an EXPERIMENTAL feature and is subject to change until it has received more real world testing.