Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

configuring actor system and dispatchers #762

Merged
merged 1 commit into from

4 participants

@nraychaudhuri
Collaborator

The "application" actor system is now created using the config under play. I think its a right thing to do so that actor system doesn't get created with some other config in the path.

One the bigger note I think it makes sense to have only one actor system for entire application with specific dispatcher for play vs. application code.

@jroper
Owner

The problem with changing the AkkaPlugin configuration to use play is that it means we now have the same problem as before, where we have two actor systems using the same configuration, checkout play.core.Invoker. It creates the internal actor system, also under the path of play. So, if you try to configure remoting, both will use the same remoting config, both will try to listen on the same port, and one will fail.

Having thought about it a bit, I think it makes sense for us to use two actor systems. The reason comes mainly from dev mode (maybe we could make prod mode do something else). If users are setting up any actors and/or scheduled tasks and the like in Global when the system starts, then when the system shutsdown (ie, reloads), we need those actors and scheduled tasks to be shut down. Currently, this is very easy because we just shut down the application actor system. But if that was the same as the Play internal actor system, then we couldn't do that, since it's likely that the thread thats shutting it down and starting it up again is a thread in the internal actor system. So that actor system needs to keep running across reloads.

@jroper
Owner

Scratch that, I just realised that Play only uses the internal actor system for user code anyway (it uses a Java executor for internal thread pools), so it should be fine for us to use the same one. But not in Play 2.1.x. For Play 2.2.x, we should make play.api.libs.concurrent.Execution.defaultContext just use the context from the Akka plugin.

@nraychaudhuri
Collaborator

Ok. Makes sense

@freneticpixel freneticpixel referenced this pull request from a commit in freneticpixel/Play20
@jroper jroper [#762] Always use utf-8 when converting Strings to bytes in Crypto 3e43eca
@guillaumebort guillaumebort commented on the diff
...n/manual/detailledTopics/configuration/ThreadPools.md
@@ -66,7 +66,7 @@ The default thread pool can be configured using standard Akka configuration in `
```
play {
akka {
- event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
+ event-handlers = ["akka.event.Logging$DefaultLogger", "akka.event.slf4j.Slf4jEventHandler"]
@guillaumebort Owner

How does this impact the actual logging?

@nraychaudhuri Collaborator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@nraychaudhuri nraychaudhuri referenced this pull request
Closed

Update ThreadPools.md #786

@guillaumebort

Ok for me then.

@jroper jroper commented on the diff
framework/src/play/src/main/resources/reference.conf
((6 lines not shown))
loglevel = WARNING
actor {
-
- deployment {
-
- /actions {
- router = round-robin
- nr-of-instances = 24
- }
-
- }
-
retrieveBodyParserTimeout = 1 second
@jroper Owner
jroper added a note

I think we can remove this too, it was only used when we were using actors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jroper jroper merged commit d1f2e40 into playframework:master
@quelgar

A side effect of this change is that the user of Play must use different keys to pass configuration to Akka in Play 2.1.1 vs 2.1.0.

For example, if I want to set up a custom dispatcher in Play 2.1.0:

my-dispatcher.mailbox-type = "akka.dispatch.UnboundedDequeBasedMailbox"

In Play 2.1.1, this is no longer visible to Akka, it must be changed to:

play.my-dispatcher.mailbox-type = "akka.dispatch.UnboundedDequeBasedMailbox"

Was this intentional?

Owner

Hmm... that was unintentional, there are two different actor systems, and the one used by Play was meant to not be namespaced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Feb 20, 2013
  1. @nraychaudhuri
This page is out of date. Refresh to see the latest.
View
56 documentation/manual/detailledTopics/configuration/ThreadPools.md
@@ -66,7 +66,7 @@ The default thread pool can be configured using standard Akka configuration in `
```
play {
akka {
- event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
+ event-handlers = ["akka.event.Logging$DefaultLogger", "akka.event.slf4j.Slf4jEventHandler"]
@guillaumebort Owner

How does this impact the actual logging?

@nraychaudhuri Collaborator
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
loglevel = WARNING
actor {
default-dispatcher = {
@@ -90,7 +90,7 @@ In certain circumstances, you may wish to dispatch work to other thread pools.
```scala
object Contexts {
- implicit val myExecutionContext: ExecutionContext = Akka.system.dispatchers.lookup("my-context")
+ implicit val myExecutionContext: ExecutionContext = Akka.system.dispatchers.lookup("akka.actor.my-context")
}
```
@@ -135,7 +135,7 @@ Below we outline a few common profiles that people may want to use in Play Frame
### Pure asynchronous
-In this case, you are doing no blocking IO in your application. Since you are never blocking, the default configuration of one thread per processor suits your use case prefectly, so no extra configuration needs to be done. The Play default execution context can be used in all cases.
+In this case, you are doing no blocking IO in your application. Since you are never blocking, the default configuration of one thread per processor suits your use case perfectly, so no extra configuration needs to be done. The Play default execution context can be used in all cases.
### Highly synchronous
@@ -166,43 +166,45 @@ This profile is recommended for Java applications that do synchronous IO, since
This profile is for when you want to do a lot of synchronous IO, but you also want to control exactly how much of which types of operations your application does at once. In this profile, you would only do non blocking operations in the default execution context, and then dispatch blocking operations to different execution contexts for those specific operations.
-In this case, you might create a number of different execution contexts for different types of opreations, like this:
+In this case, you might create a number of different execution contexts for different types of operations, like this:
```scala
object Contexts {
- implicit val simpleDbLookups: ExecutionContext = Akka.system.dispatchers.lookup("simple-db-lookups")
- implicit val expensiveDbLookups: ExecutionContext = Akka.system.dispatchers.lookup("expensive-db-lookups")
- implicit val dbWriteOperations: ExecutionContext = Akka.system.dispatchers.lookup("db-write-operations")
- implicit val expensiveCpuOperations: ExecutionContext = Akka.system.dispatchers.lookup("expensive-cpu-operations")
+ implicit val simpleDbLookups: ExecutionContext = Akka.system.dispatchers.lookup("akka.actor.simple-db-lookups")
+ implicit val expensiveDbLookups: ExecutionContext = Akka.system.dispatchers.lookup("akka.actor.expensive-db-lookups")
+ implicit val dbWriteOperations: ExecutionContext = Akka.system.dispatchers.lookup("akka.actor.db-write-operations")
+ implicit val expensiveCpuOperations: ExecutionContext = Akka.system.dispatchers.lookup("akka.actor.expensive-cpu-operations")
}
```
These might then be configured like so:
```
-akka {
- actor {
- simple-db-lookups {
- fork-join-executor {
- parallelism-factor = 10.0
+play {
+ akka {
+ actor {
+ simple-db-lookups {
+ fork-join-executor {
+ parallelism-factor = 10.0
+ }
}
- }
- expensive-db-lookups {
- fork-join-executor {
- parallelism-max = 4
+ expensive-db-lookups {
+ fork-join-executor {
+ parallelism-max = 4
+ }
}
- }
- db-write-operations {
- fork-join-executor {
- parallelism-factor = 2.0
+ db-write-operations {
+ fork-join-executor {
+ parallelism-factor = 2.0
+ }
}
- }
- expensive-cpu-operations {
- fork-join-executor {
- parallelism-max = 2
+ expensive-cpu-operations {
+ fork-join-executor {
+ parallelism-max = 2
+ }
}
}
- }
+ }
}
```
@@ -210,4 +212,4 @@ Then in your code, you would create futures and pass the relevant execution cont
### Few specific thread pools
-This is a combination between the many specific thread pools and the highly synchronised profile. You would do most simple IO in the default execution context and set the number of threads there to be reasonably high (say 100), but then dispatch certain expensive operations to specific contexts, where you can limit the number of them that are done at one time.
+This is a combination between the many specific thread pools and the highly synchronized profile. You would do most simple IO in the default execution context and set the number of threads there to be reasonably high (say 100), but then dispatch certain expensive operations to specific contexts, where you can limit the number of them that are done at one time.
View
26 framework/src/play/src/main/resources/reference.conf
@@ -6,35 +6,11 @@ promise.akka.actor.typed.timeout=5s
play {
akka {
- event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
+ event-handlers = ["akka.event.Logging$DefaultLogger", "akka.event.slf4j.Slf4jEventHandler"]
loglevel = WARNING
actor {
-
- deployment {
-
- /actions {
- router = round-robin
- nr-of-instances = 24
- }
-
- }
-
retrieveBodyParserTimeout = 1 second
@jroper Owner
jroper added a note

I think we can remove this too, it was only used when we were using actors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
-
- actions-dispatcher = {
- fork-join-executor {
- parallelism-factor = 1.0
- parallelism-max = 24
- }
- }
-
- websockets-dispatcher = {
- fork-join-executor {
- parallelism-factor = 1.0
- parallelism-max = 24
- }
- }
default-dispatcher = {
fork-join-executor {
View
2  framework/src/play/src/main/scala/play/api/libs/concurrent/Akka.scala
@@ -59,7 +59,7 @@ class AkkaPlugin(app: Application) extends Plugin {
lazy val applicationSystem: ActorSystem = {
applicationSystemEnabled = true
- val system = ActorSystem("application", app.configuration.underlying, app.classloader)
+ val system = ActorSystem("application", app.configuration.underlying.getConfig("play"), app.classloader)
Logger("play").info("Starting application default Akka system.")
system
}
View
2  framework/test/integrationtest/test/FunctionalSpec.scala
@@ -79,7 +79,7 @@ class FunctionalSpec extends Specification {
browser.goTo("/conf")
browser.pageSource must contain("This value comes from complex-app's complex1.conf")
browser.pageSource must contain("override akka:2 second")
- browser.pageSource must contain("akka-loglevel:DEBUG")
+ browser.pageSource must contain("akka-loglevel:WARNING")
browser.pageSource must contain("promise-timeout:7000")
browser.pageSource must contain("None")
browser.title must beNull
Something went wrong with that request. Please try again.