All geek questions in one place

Stream Architecture

The game has been described as a "reactive" structure, useful for asynchronous programming. I would like to learn more about game architecture, mainly:

  • Is there an event loop?

  • Does he have many chord systems acca? Are they supported by multiple thread pools?

  • If so, how many thread pools exist and what are their goals (routing, request processing, promising repayment, abnormal, etc.)

  • What is the thread of execution that we can block (where can we do some expensive calculations)? What thread should we never block?

Any resource / wiki / advice on this is really helpful. Thanks you

+6
source share
2 answers

Note: the following content is available for Play! 2.1.x. For Game! 2.0.4 see nico_ekitos answer.

Interaction with the client can be summarized in the following diagram:

Play! ’S architecture

Playing an HTTP handler (built on top of Netty ) lives in its own execution context. When he receives a request, he tries to find the entry point for the applications to call according to the URL (using the conf/routes application files). Currently, only HTTP request headers are loaded into memory.

Then the entry point is called. This is usually an action that loads the remaining body, if any. This happens in a different execution context, on Play! A "custom" execution context defined as Akka's Akka Manager, which can be configured in the conf/application.conf file.

Finally, inside an action, you can make asynchronous calls (for example, to call a web service ). All of these asynchronous calls use the Scala s Future API, so they use the execution context available in the scope of the call site. So you can use Play! user execution context (defined in play.api.libs.concurrent.Execution.defaultContext ).

In general, the game! uses various execution contexts for the following tasks:

  • Receive requests (Netty HTTP handler)
  • call actions (user execution context).

And you can use any execution context that you want for your asynchronous calculations (including the Play user's execution context!).

The idea is that all user codes use Play by default. user execution context. If you block it, you will not be able to run more user code, but you can continue to do the rest.

If you are doing expansive calculations, I suggest you use a dedicated execution context.

+7
source

Take a look at the default configuration of Akka and the list of members on Play! wiki .

+1
source

Source: https://habr.com/ru/post/926466/

More articles:


All Articles