configuring actor system and dispatchers #762

Merged
merged 1 commit into from Mar 12, 2013

Projects

None yet

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
Member
jroper commented Feb 21, 2013

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
Member
jroper commented Feb 21, 2013

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 pushed a commit to freneticpixel/Play20 that referenced this pull request Feb 22, 2013
@jroper jroper [#762] Always use utf-8 when converting Strings to bytes in Crypto 3e43eca
@guillaumebort guillaumebort commented on the diff Mar 5, 2013
...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
guillaumebort Mar 5, 2013 Collaborator

How does this impact the actual logging?

@nraychaudhuri
nraychaudhuri Mar 5, 2013 Collaborator

Actually it doesn't impact anything. Now instead of relying on the
reference.conf from akka we configure the event handlers inside play.
Before my mistake Play was using some settings from akka's reference.conf

Nilanjan

On Tue, Mar 5, 2013 at 5:04 AM, Guillaume Bort notifications@github.comwrote:

In 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"]

How does this impact the actual logging?


Reply to this email directly or view it on GitHubhttps://github.com/playframework/Play20/pull/762/files#r3240517
.

@nraychaudhuri nraychaudhuri referenced this pull request Mar 5, 2013
Closed

Update ThreadPools.md #786

@guillaumebort
Collaborator

Ok for me then.

@jroper jroper commented on the diff Mar 11, 2013
framework/src/play/src/main/resources/reference.conf
loglevel = WARNING
actor {
-
- deployment {
-
- /actions {
- router = round-robin
- nr-of-instances = 24
- }
-
- }
-
retrieveBodyParserTimeout = 1 second
@jroper
jroper Mar 11, 2013 Member

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

@jroper jroper merged commit d1f2e40 into playframework:master Mar 12, 2013
@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?

Member

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