A stop strategy is a supervision decision that terminates an actor after it fails. The actor no longer participates in message processing. It is the safest default when the cause of an exception is uncertain or may persist, rather than disappear on a retry. section 5.1.2 section 5.3.2
Stopping supports fault isolation: a supervisor can remove a faulty actor without requiring every other actor to manage its failure directly. It differs from restart, which creates a new actor instance that continues reading from the same mailbox through the same ActorRef, and from resume, which keeps the existing instance processing messages. section 5.1.2
Failure, cleanup, and termination
When a message causes an exception, the supervisor selects stopping and the actor moves to a failed behavior. The system then delivers PostStop, giving the actor one final opportunity to close connections, files, or expiring resources. After PostStop is handled, no further mailbox messages are processed; the mailbox, supervisor, and actor are deleted together. section 5.3.2
Stopping avoids blindly retrying a message that may itself be defective. For example, a LogProcessor that repeatedly receives a corrupted file or unparseable line can become stuck processing only that failing input. Failed messages are not left in the mailbox by default; reprocessing requires an explicit choice and confidence that the message did not cause the error. section 5.1.2
Trace the default sequence from a failed message through supervisor handling to PostStop and actor termination. section 5.3.2
Configure supervised stopping
Wrap an actor behavior with Behaviors.supervise and select SupervisorStrategy.stop for failures. Handle PostStop with receiveSignal when the actor owns resources that need cleanup; signals come from the actor system rather than the actor’s normal message protocol. section 5.3.2
