The Dispatcher parsing

The Dispatcher decouples how the task is performed from when it is run, and the work of the Actor or Future is done by the resources assigned to it (Executor or Dispatcher). Typically, the Dispatcher will contain threads that schedule and run tasks, such as processing messages from actors and Future events in the thread.

If the Dispatcher is not created by ourselves, the default Dispathcer is used. If there are some time-consuming tasks in the task, the default thread pool will be filled up easily, affecting the scheduling of other tasks.

Excutor

Dispatcher is based on Executors, so before we get into the details of Dispatchers, we will introduce two main types of executors: ForkJoinPool and ThreadPool.

  • ThreadPool Excutor: There is a work queue that contains work assigned to each queue. Threads can claim work from the queue when idle, allowing threads to reuse work and reducing thread allocation and destruction overhead.
  • ForkJoinPool Excutor: : Uses a divide-and-conquer algorithm to recursively divide tasks into smaller sub-tasks, then assign the sub-tasks to different threads to run, and finally combine the results of the runs.

ForkJoinPool executors are almost always more efficient than ThreadPool executors and are our default choice.

Create the Dispatcher

  1. Define a Dispatcher in the application.conf file.

    my-dispatcher {
  #Select the type of Dispatcher that matches the scenario. The default type Dispatcher is used here
  type = Dispatcher
  #Define the Excutor type. There are also two Excutor types described aboveExecutor = "fork-join-executor" fork-join-executor {# Minimum number of threads in a single thread, If the number of threads in the Excutor is 1, the number of threads in the Excutor is 2. If the number of threads in the Excutor is 2, the number of threads in the Excutor is 3 Parallelism - Max *parallelism-factor parallelism- Max = 1000}  #The maximum number of messages to be processed by each Actor before jumping to another Acotr. To prevent a single Acotr from occupying threads, set the maximum number of messages to be executed by this Acotr
  throughput = 1000
}
Copy the code

  2. Create a Dispatcher object using the Dispatcher configured in application.confg

    system.actorOf(Props[MyActor].withDispatcher("my-pinned-dispatcher"))
Copy the code

There are four types of dispatchers that can be used in Akka to describe how threads are shared between actors:

Type Characteristics of the
Dispatcher Default Dispatcher type. Messages will be processed in the Actor using the defined Executor. In most cases, this type provides the best performance.
PinnedDispatcher Each Actor is assigned its own unique thread. This type of Dispatcher creates a ThreadPool Executor for each Actor, and each Executor contains a thread.

If you want to ensure that every Actor responds immediately, this seems like a good way to do it. But PinnedDispatcher is not often more efficient than other methods of sharing resources. You can try this type of Dispatcher when a single Actor must handle a lot of important work, but it is not recommended otherwise.
CallingThreadDispatcher This Dispatcher is special in that it does not have an Executor, but instead performs its work on the thread that initiates the call. This Dispatcher is primarily used for testing, especially debugging. Because the calling thread is responsible for doing the work, you can clearly see the stack trace information and understand the complete context of the method being executed. This is very useful for understanding exceptions. Each Actor takes a lock, so only one thread can execute code in the Actor at a time, and if multiple threads send information to an Actor, all threads except the one that owns the lock will be in a wait state. TestActorRef, described earlier in this book, is based on the CallingThreadDispatcher implementation that supports synchronous execution in tests.
BalancingDispatcher BalancingDispatcher is unique in that all actors in the Pool share the same mailbox and creates a thread for each Actor in the Pool. Actors using BalancingDispatcher pull messages from mailboxes, so as long as any Actor is idle, no Actor has a job in the work queue. This is a variation on job theft, where all actors pull tasks from a shared mailbox. The performance benefits are similar.

reference

  • Introduction and Practice of Akka

The concerned public account replied to Akka to receive the book “Akka Introduction and Practice”

Follow public accountData craftsman notes, focus on big data field offline, real-time technology dry goods regular sharing! Personal websitewww.lllpan.top