Confusion on implicit ExecutionContext provided by Play and Scala

[Tianhao Li]

Before upgrade to Play 2.5, I remember the docs said (even 2.5 now):

https://www.playframework.com/documentation/2.5.x/ThreadPools

Play recommends using 

import play.api.libs.concurrent.Execution.Implicits._

However, when I use the new activator to create Play 2.5 template project, for example

import scala.concurrent.{ExecutionContext, Future, Promise}
import scala.concurrent.duration._


/**
 * This controller creates an `Action` that demonstrates how to write
 * simple asychronous code in a controller. It uses a timer to
 * asynchronously delay sending a response for 1 second.
 *
 * @param actorSystem We need the `ActorSystem`'s `Scheduler` to
 * run code after a delay.
 * @param exec We need an `ExecutionContext` to execute our
 * asynchronous code.
 */
@Singleton
class AsyncController @Inject() (actorSystem: ActorSystem)(implicit exec: ExecutionContext) extends Controller {

Here, the ExecutionContext is from Scala, my question here is which one we should use. If we use the ExecutionContext provided by Scala, can we get the benefit of Play optimising performance stuff?

Which is pretty confused.

[Greg Methvin]

Actually, in the case of that controller, the ExecutionContext is a constructor parameter that is injected. Play binds its own internal ExecutionContext, so that will be used when the DI framework creates the controller. play.api.libs.concurrent.Execution.Implicits.defaultContext refers to the same ExecutionContext as is used there. Of course, since it's just a constructor parameter, you can easily run the controller with a different execution context if you want.

If you wanted to use default scala ExecutionContext, you would import scala.concurrent.ExecutionContext.Implicits.global.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/e0461318-21a4-44c8-b7f9-5bc711ee4c6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Greg Methvin

Senior Software Engineer

Lightbend, Inc.

[Alexandr Chigrinets]

If it's just a constructor parameter, then how to inject my own execution context to this controller using DI container instead of explicitly import it in package?

понедельник, 7 марта 2016 г., 11:52:39 UTC+3 пользователь Greg Methvin написал:

[Greg Methvin]

In Guice you could use a binding annotation on the constructor parameter to specify a different execution context. Basically it's the same strategy you'd use for binding ActorRef's for different actors.

To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/2d164c80-a82e-43eb-829f-89a04bbf33e8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Taner Sener]

Hi,

I'm trying to use a custom dispatcher for my controller. Injecting custom ExecutionContext with @Named annotation or getting ExecutionContext using dispatchers lookup didn't work for me.

In the following code, "Processing outer request" log line is always executed by default dispatcher threads. Do you have any recommendations, am I trying to achieve something impossible?

@Singleton

class MyController @Inject() (actorSystem: ActorSystem) extends play.api.mvc.Controller {

    private val controller1ThreadPool: MessageDispatcher = actorSystem.dispatchers.lookup("akka.actor.contexts.controller-1-thread-pool")

    def asyncAction = Action.async {

      logger.info("Processing outer request")

      

      val futureInt = scala.concurrent.Future {

            logger.info("Processing inner request")

      } (controller1ThreadPool)

        futureInt.map(i => Ok("Result: " + i)) (controller1ThreadPool)

    }

}