A child actor can be forced to stop after it finishes processing its current message by using the stop method of the ActorContext from the parent actor. Only child actors can be stopped in that way.
There is also a stop method in the ActorContext but it can only be used for stopping direct child actors and not any arbitrary actor.
Is this limitation a deliberate design choice? If so, what is the rationale? Perhaps Akka’s developers realized that the capability of stopping someone else’s child brings more disadvantages and complexity than advantages?
What are the pros and cons of being able (or not able) to stop arbitrary, non-child actors?
So, it’s unlikely a “designer” will respond, so we can only make logical conclusions and look at the docs and code.
First, you absolutely can stop an arbitrary, non-child actor. That’s what a PoisonPill and Kill messages do. And even if didn’t have Kill messages out of the box we could easily create them with things like Control and Priority mailboxes.
So the more accurate question might be, “Why is the parent the only one that can call the stop method when there are so many other ways to stop an actor?”
My theory would be because the actual “stopping” of an actor is done by the parent, as the guardian of the child. (At least IIRC.) Also, unlike any arbitrary actor, we know that the parent and child are local to each other, and any lifecycle events are tightly coupled between them because its role as the guardian of the child.
This ability of a parent to interact with a child via a method (rather than a message) is a bit of an exception to the “the only way to interact with an actor is to send a message to it” concept in the actor model. Again, I’d posit that is likely because of the special relationship the parent has as a guardian in the lifecycle of the child.
You’re on the right track, David! I was the one who implemented this in 2012 — not all details are fresh in my mind but I’ll give you the best I recall.
The starting point is indeed that Akka differs from previous actor implementations in making supervision mandatory: every actor has a parent. Supervision trees in Erlang informed the design principle that the lifecycle of a child actor is bounded by its parent — this applies to creation as well as termination.
side note: remote deployment allows parent and child to reside on different ActorSystems!
While actors can be told to stop using normal messages (of which PoisonPill is one), creation and termination are signaled using a different mechanism: SystemMessage. These lifecycle notifications do not go through the mailbox, they jump the queue and are always treated immediately (i.e. after the currently processing message if there was one).
Removing race conditions and ensuring correct handling of all lifecycle events (where remote deployment was an especially hairy ball of problems) turned out to require that the parent needs to be the one party that can initiate lifecycle changes — everything else broke in various ways. You might try to hack a termination signal into a custom mailbox implementation, but the result would be equally broken, so I don’t recommend that.
To conclude: in addition to the philosophical argument of actor autonomy (i.e. only voluntary termination from the outside) there were technical reasons for this choice.
Thanks, I don’t really consider myself an expert anymore, I’ve been away from Akka as my day to day tool for a while. I just didn’t think Roland/Jonas/Viktor (sorry for not listing everyone) would jump in. I’m glad Roland did, and I’m glad I had the gist of it.