A lifecycle describes how an operational component moves from startup through active work to stopping, replacement, restart, or removal. In actor systems, lifecycle management is a first-class capability rather than custom plumbing around ordinary objects: actors are active components that can be started, stopped, and restarted. section 5.1.1 section 5.1.2
Plain objects have only construction and eventual garbage collection by default. Replacing or rebooting one requires application-built indirection, reconstruction of dependencies, careful ordering when dependencies also fail, and multithreaded safeguards. Direct references make isolation difficult, while exception handling can become tangled with normal processing. section 5.1.1
Recovering a failed log-processing component
Consider a FileWatcher sending logs through a LogProcessor and Writer to a database. If a database connection fails in a directly connected object design, calls can unwind through the stack and lose input context; buffering, retries, and concurrent-failure control must be added manually. With actors, the supervisor can wrap the failing behavior, suspend its mailbox after a crash, then choose a recovery action. It may restart the actor, replace it with a fresh instance recreated from its Behavior, stop it, or use a different replacement that connects to another database. Other actors keep communicating through actor references rather than needing to track the old instance directly. section 5.1.1 section 5.1.2
Figure 5.6 Supervisor wrapping an actor’s behavior and deciding on a recovery action after an exception
The supervision wrapper separates normal message processing from the recovery decision made after an exception. section 5.1.2
Place lifecycle boundaries deliberately in an actor hierarchy:
- Keep actors most likely to crash low in the hierarchy, where more actors can handle or monitor their faults. section 5.1.2
- Avoid failures near the ActorSystem top level, where recovery can restart all top-level actors or shut down the system. section 5.1.2
- Treat recovery as separate from functional behavior: supervision defines fault handling independently of normal message processing. section 5.1.2
Lifecycle also applies to cluster nodes. A node follows a state machine from Joining to Removed, passing through WeaklyUp, Up, Leaving, Down, and Exiting. When nodes are shut down and new ones are created, actors can run on different nodes while the word-counting application continues counting without lost work. section 8.6
