com.r3corda.node.services.statemachine / StateMachineManager / <init>

# <init>

`StateMachineManager(serviceHub: ServiceHubInternal, checkpointStorage: CheckpointStorage, executor: AffinityExecutor)`

A StateMachineManager is responsible for coordination and persistence of multiple ProtocolStateMachine objects. Each such object represents an instantiation of a (two-party) protocol that has reached a particular point.

An implementation of this class will persist state machines to long term storage so they can survive process restarts and, if run with a single-threaded executor, will ensure no two state machines run concurrently with each other (bad for performance, good for programmer mental health).

A "state machine" is a class with a single call method. The call method and any others it invokes are rewritten by a bytecode rewriting engine called Quasar, to ensure the code can be suspended and resumed at any point.

The SMM will always invoke the protocol fibers on the given AffinityExecutor, regardless of which thread actually starts them via add.

TODO: Session IDs should be set up and propagated automatically, on demand. TODO: Consider the issue of continuation identity more deeply: is it a safe assumption that a serialised continuation is always unique? TODO: Think about how to bring the system to a clean stop so it can be upgraded without any serialised stacks on disk TODO: Timeouts TODO: Surfacing of exceptions via an API and/or management UI TODO: Ability to control checkpointing explicitly, for cases where you know replaying a message cant hurt TODO: Make Kryo (de)serialize markers for heavy objects that are currently in the service hub. This avoids mistakes where services are temporarily put on the stack. TODO: Implement stub/skel classes that provide a basic RPC framework on top of this.