Problem using Custom Dispatchers in Akka 2.0 M3/M4

[Philip]

Hi all,

I tried to use a custom dispatcher as described in
http://akka.io/docs/akka/2.0-M4/scala/dispatchers.html:
val configString = """
akka {
logConfigOnStart=on
actor {
my-dispatcher {
# Dispatcher is the name of the event-based dispatcher
type = Dispatcher
# ...
}
}
}
"""

Due to the "logConfigOnStart=on" parameter I verified that the Akka
system started with the custom dispatcher declared.

I try to use the dispatcher like this:
system = ActorSystem("DispatcherTest",
ConfigFactory.parseString(configString))
val workerActor =
system.actorOf(Props().withCreator(config.workerFactory.createInstance(workerId,
config)).withDispatcher("my-dispatcher"), name = workerName)

When executing the code this results in the following warning:
[Dispatchers] Dispatcher [my-dispatcher] not configured, using
default-dispatcher

Am I using this wrong or missing something obvious? Thank you very
much for your help.

An additional question that I have been wondering about: What's the
advantage of specifying the configuration using a configuration file
compared to doing it programmatically with the builder pattern? Having
a configuration statically checked while writing it and being able to
use code completion is very nice. Also it would probably simplify
writing code that extends an existing configuration; manually
concatenating string fragments is error prone and not very elegant.

Thanks again for your time,
Philip

[rkuhn]

Am Mittwoch, 8. Februar 2012 15:34:00 UTC+1 schrieb Philip:

Hi all,

I tried to use a custom dispatcher as described in
http://akka.io/docs/akka/2.0-M4/scala/dispatchers.html:
val configString = """
akka {
  logConfigOnStart=on
  actor {
          my-dispatcher {
          # Dispatcher is the name of the event-based dispatcher
          type = Dispatcher
          # ...
          }

It should be clarified in the docs that the dispatcher-id is actually the path into the config, i.e. you would use this dispatcher as “akka.actor.my-dispatcher”. The sample in the docs just puts the dispatcher section at the top level of the configuration file.

Regards,

Roland
 

  }
}
"""

Due to the "logConfigOnStart=on" parameter I verified that the Akka
system started with the custom dispatcher declared.

I try to use the dispatcher like this:
    system = ActorSystem("DispatcherTest",
ConfigFactory.parseString(configString))
    val workerActor =
system.actorOf(Props().withCreator(config.workerFactory.createInstance(workerId,
config)).withDispatcher("my-dispatcher"), name = workerName)

When executing the code this results in the following warning:
    [Dispatchers] Dispatcher [my-dispatcher] not configured, using
default-dispatcher

Am I using this wrong or missing something obvious? Thank you very
much for your help.

An additional question that I have been wondering about: What's the
advantage of specifying the configuration using a configuration file
compared to doing it programmatically with the builder pattern? Having
a configuration statically checked while writing it and being able to
use code completion is very nice. Also it would probably simplify
writing code that extends an existing configuration; manually
concatenating string fragments is error prone and not very elegant.

The ID-based approach was chosen so that it is trivial to serialize Props and send them to a remote node. I agree that it is not all that necessary when just using Akka locally, so this is a consequence of the “location transparency” theme.

Regards,

Roland

[Philip]

Hi Roland,

> It should be clarified in the docs that the dispatcher-id is actually the
> path into the config, i.e. you would use this dispatcher as
> “akka.actor.my-dispatcher”. The sample in the docs just puts the dispatcher
> section at the top level of the configuration file.

Thank you very much for the quick help, it works now!
I hadn't realized that the id was an access-path.

> The ID-based approach was chosen so that it is trivial to serialize Props
> and send them to a remote node. I agree that it is not all that necessary
> when just using Akka locally, so this is a consequence of the “location
> transparency” theme.

Thanks for the explanation, I guess don't understand well enough how
the choice relates to location transparency (Java serialization ->
base64 string should be trivial too).

Kind regards,
Philip

[rkuhn]

Hi Philip,

the dispatcher (configurator) would have to be serializable in your scenario, which while possible seems not desirable because such a thing might want to hang on to some nasty things like thread pools and some such. Of course that can be done right, but it's much harder to get wrong in the current scheme.

Regards,

Roland