Akka Java Fault Tolerance and Restart

Question

I am currently studying fault tolerance and supervisor strategies in Akka (Java version).

at ... http://doc.akka.io/docs/akka/2.3.2/java/fault-tolerance.html and http://doc.akka.io/docs/akka/2.3.2/general/ supervision.html # supervision

A few questions:

1) Should we ever use try / catch blocks in our actors when we know what exceptions to expect? Why or why not? If not, should we rely on a supervisor strategy to effectively handle the exceptions a child could throw?

2) By default, if the supervisor is not explicitly configured in the parent actor, it looks like any child actor that throws an exception will be reset by default. What if none of your actors in your entire system have a state ... Should we really do reboots?

3) What if your top-level actors created by system.actorOf (...) raise an exception? How do you provide a supervisor strategy outside the cast system?

4) Assume that the scenario in which actor A has a child actor B. Now let's say that actor A asks actor B to do some work.

Some code might look like this:

Future<Object> future = Patterns.ask(child, message, timeout); future.onComplete(new OnComplete<Object>() { @Override public void onComplete(Throwable failure, Object result) throws Throwable { ... handle here } 

Now ... what if actor A somehow throws an exception. By default, it is rebooted by the supervisor. The question is, is the “close” onComplete still being executed in the future, or is it effectively “destroyed” upon reboot?

5) Suppose I have a hierarchy such as: A-> B-> C. Suppose also that I redefine preRestart so that I DO NOT actually stop my children. In A prestart, it calls getContext (). ActorOf (B), and in B preart, it calls getContext (). ActorOf (C). If A throws an exception, will there be more than one actor B and there will be more than one actor C in the system?

Thanks!

Answer 1

This will be a fairly long answer, but let me resolve your issues as orderly as possible.
In addition, I will rely on the official documentation of Akka, as I believe that Akka is one of the best documented projects, and I do not want to reinvent the wheel. :)

• A good introduction / review of how fault tolerance works in Akka, [1] . I think the article summarizes quite a few pages of Akka documents. To specifically answer this question, I think it depends: you can try/catch exceptions, of course, but the Error Cell Label states that you need to “squeeze the actors hierarchy”, which may fail (this is to prevent or limit as much as possible the loss of state within the participants). This suggests that if you have a very specific Exception and you know how to handle it as part of message processing, I don't think there is any kind of internal problem in catching it. In fact, I can think of at least one specific case where you want to detect exceptions and handle them: if your subject responds to Pattern.ask , you need to wrap the exceptions in Failure if you want the caller to be notified. ( [2] ).

• As indicated in [3] , the default behavior is indeed Restart , but only if a Exception thrown during message processing. Note that ActorInitializationException and ActorKilledException will by default terminate the child element and keep in mind that any Exception preStart inside the preStart will be wrapped in an ActorInitializationException . As for whether Restart default sound “in case you don't have state in your actors” ... well, an actor is by definition an abstraction of safe access and state management in a parallel environment: if you can't use Future instead of actors , perhaps. Overall, Restart was considered a safe and reasonable default for a typical use case. In your particular case (which is not a typical precedent for an actor system), you can redefine the default surveillance strategy in any case.

• Top-level actors are top-level only from the point of view of the user. As explained in [4] , any top-level actor is created as a child of the Guardian actor, and he has a standard default surveillance strategy. In addition, you can change this default value using the akka.actor.guardian-supervisor-strategy property. Also, keep in mind that you should always design your systems while preserving the hierarchical nature of Akka ( [5] ), so don't use top-level players too much ( [6] ).

• The call of the called calls onComplete s or does not depend on when A fails. If he completed after B and answered the As request, he can execute. Otherwise this will not happen. It is "destroyed" when with an old instance.

• This is a bit confusing, but I assume the following:

  • When you say: “ A throws an exception”, you mean in message processing ( onReceive )
  • You have a field in your actor that will store the link returned by getContext().actorOf(C) .

The quick answer is yes . Given the scenario you described, several instances of B and C will be present. However, the new instance of A not aware of this. It will refer to new B and, indirectly, new C This is reasonable and expected, because you have manually and explicitly disabled the standard part of the cleanup logic that handles failures in the actor hierarchy (by changing postRestart ): now it is not your responsibility to clean up and implement the preStart that you describe.