Home/ Questions/Q 8810807
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T03:12:29+00:00

Play has been described as a ‘reactive’ framework, being useful for async programming. I’d

  • 0

Play has been described as a ‘reactive’ framework, being useful for async programming. I’d like to know more about play’s architecture, mainly:

  • Does it have an event loop?

  • Does it have many akka actor systems? are they backed by a number of thread pools?

  • If so how many thread pools are there and what are they objectives (routing, request handling, promise redeeming, anorm, etc.)

  • Which is the thread of execution we are ok to block (where can we make some expensive computation)? Which is the thread of execution we should never ever block?

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Note: the following content holds for Play! 2.1.x. For Play! 2.0.4 see nico_ekito’s answer.

    The interactions with a client can be summarized by the following chart:

    Play!’s architecture

    Play’s HTTP handler (built on top of Netty) lives in its own execution context. When it receives a request, it tries to find the application’s entry point to call according to the URL (using the application’s conf/routes file). At this point, only the headers of the HTTP request are loaded in memory.

    Then, the entry point is called. It is usually an action, which loads the remaining body, if any. This happens in a different execution context, the Play! “user” execution context, defined as an Akka actor dispatcher that can be configured in the applications’s conf/application.conf file.

    Finally, inside an action you can perform asynchronous calls (e.g. to call a Web Service). All these asynchronous calls use Scala’s Future API, so they use the execution context available in the scope at the call site. So you can use the Play! “user” execution context (defined in play.api.libs.concurrent.Execution.defaultContext).

    In summary, Play! uses distinct execution contexts for the following tasks:

    • receive requests (Netty HTTP handler) ;
    • call actions (“user” execution context).

    And you are free to use whatever execution context you want for your asynchronous computations (including the Play! “user” execution context).

    The idea is that all user code uses by default the Play! “user” execution context. If you block it you won’t be able to run more user code but can continue doing everything else.

    If you’re doing expansive computations I suggest you to use a dedicated execution context.

    • 0