Supervision

The concept of fault tolerance is related to actors, and the fault-tolerance processing in Actor model is called supervision. The core idea of supervision is to separate the failure response from the components that may cause the failure, and to organize the components that may cause the failure through a hierarchical structure for easy management.

In a distributed system where every component is a time bomb, we want to be sure that if any one of them explodes, it doesn’t set off a chain reaction that causes the other components to explode. Alternatively, we want to be able to isolate errors, or separate components that might cause a failure.

The hierarchy of supervision

Akka uses an Actor hierarchy to describe oversight. When we create actors, each new Actor acts as a child of another Actor, with the parent overseeing the child. The Actor path structure shows its hierarchy, so it’s a bit like a folder in a file system.

Supervision strategy

In the Akka framework, the parent Actor supervises the child Actor and monitors whether the behavior of the child Actor is abnormal. In general, there are two types of monitoring strategies:

  1. OneForOneStrategy: The parent Actor only deals with the child actors that have problems. Such as restarting or stopping. The default Akka policy is recommended.
  2. AllForOneStrategy: The parent Actor treats the offending child Actor and all of its siblings. This method applies only to scenarios where actors are closely connected. If only one of multiple actors fails, the entire task is declared to have failed.

Specific processing methods in Actor mainly include the following:

  • Resume: Actor continues processing the next message;
  • Stop: Stops the Actor to do no more operations;
  • Restart: Creates a new Actor to replace the original Actor.
  • Escalate: Transmits abnormal information to the next supervisor.

Creating a Monitoring Policy

public class JavaSupervisorStrategyDemo extends AbstractActor {
    private static SupervisorStrategy strategy =
            new OneForOneStrategy(
                    10,
                    Duration.create("1 minute"),
                    /* * resume(): Actor continues to process the next message; * restart(): stops the Actor from doing anything else; * Escalate (): Creates an Actor instead of the original Actor; * stop(): passes exception information to the next supervisor; * /
                    DeciderBuilder.match(ArithmeticException.class, e -> SupervisorStrategy.resume())
                            .match(NullPointerException.class, e -> SupervisorStrategy.restart())
                            .match(IllegalArgumentException.class, e -> SupervisorStrategy.stop())
                            .matchAny(o -> SupervisorStrategy.escalate())
                            .build());

    @Override
    public SupervisorStrategy supervisorStrategy(a) {
        returnstrategy; }}Copy the code

A one-to-one strategy means that each child is treated individually. In the example above, 10 and duration.create (1, timeUnit.minutes) are passed to the maxNrOfRetries and withinTimeRange parameters, respectively, which means that the policy restarts a child up to 10 times per minute. If the restart count exceeds maxNrOfRetries during the withinTimeRange duration, the child Actor stops.

If the policy is declared in a supervisor Actor (rather than a separate class), its decision maker can have thread-safe access to all of the internal state of the Actor, including getting a reference to the child of the current failure, which can be used as a getSender() for the failure message.

Default Supervision Policy

The default behavior is generally fine: if an Actor throws an exception while running, restart the Actor; If an error occurs, report it up or close the application. But if the Actor in the constructor throws an exception, then lead to ActorInitializationException, stop running and eventually lead to the Actor.

If no oversight policy is defined for Actor, the following exceptions are handled by default:

  • ActorInitializationExceptionWill stop the failed subactor
  • ActorKilledExceptionWill stop the failed subactor
  • DeathPactExceptionWill stop the failed subactor
  • ExceptionWill restart the failed subactor
  • Other typeThrowableWill reflect up to the parent Actor

If the exception escalates all the way to the root guardian, it will handle it in the same way as the default policy defined above.

Stop monitoring strategy

Take steps to stop children when they fail, and then take corrective action by the overseer when DeathWatch shows that children are dead. This strategy also prepackaged for SupervisorStrategy stoppingStrategy, along with a StoppingSupervisorStrategy configuration program, so that when you want/user under guardian when apply it.

Record Actor failures

By default, unless escalate is reflected upward, the container is designed to record failures. Failures in the escalate should be processed at a higher level in the hierarchy and recorded.

The default log container is designed to be silent by setting loggingEnabled to false on instantiation. Custom logging can be done within Decider.

Note that the reference to the currently failed child can be used as a sender when declaring the SupervisorStrategy inside the supervisor Actor.

You can also customize the logging in your container by overwriting the logFailure method.

reference

Akka Introduction and Practice — Chapter 3 Messaging

Reply to Akka to get the book Akka Introduction and Practice

Pay attention to the public number, focus on Java big data field offline, real-time technology dry goods regular sharing! Reply to Akka to get the book Akka Introduction and Practice, personal website www.lllpan.top