Actually I would redirect Akka logging to slf4j and use this API directly in all unrelated classes. First add this to your configuration: akka { event-handlers = [“akka.event.slf4j.Slf4jEventHandler”] loglevel = “DEBUG” } Then choose some SLF4J implementation, I suggest logback. In your actors continue using ActorLogging trait. In other classes simply rely on SLF4J API … Read more
The conflicts appear because: you’ve specified your Scala version to be 2.11 you’ve explicitly specified the Scala version (2.10) for the reactivemongo and poi-scala libraries. The fix is to use the %% operator for those two libraries as well. “org.reactivemongo” %% “reactivemongo” % reactiveMongoVersion, “info.folone” %% “poi-scala” % foloneVersion That’s the purpose of the %% … Read more
Scala actors (including the Akka variety) use Java threads. There’s no magic: more than a few thousand threads running simultaneously is a problem for most desktop machines. The Actor model allows for awake-on-demand actors which do not occupy a thread unless they have work to do. Some problems can be modeled effectively as lots of … Read more
Avoid !? wherever possible. You will get a locked system! Always send a message from an Actor-subsystem thread. If this means creating a transient Actor via the Actor.actor method then so be it: case ButtonClicked(src) => Actor.actor { controller ! SaveTrade(trdFld.text) } Add an “any other message” handler to your actor’s reactions. Otherwise it is … Read more
This is the most comprehensive comparison I have seen so far: http://doc.akka.io/docs/misc/Comparison_between_4_actor_frameworks.pdf via http://klangism.tumblr.com/post/2497057136/all-actors-in-scala-compared
In a superficial view they’re really similar, although I personally consider more similar Vert.x ideas to some MQ system than to Akka… the Vert.x topology is more flat: A verticle share a message with other verticle and receive a response… instead Akka is more like a tree, where you’ve several actors, but you can supervise … Read more
In Play 2.0, Play delegated all requests to go through an actor. It heavily depended on Akka’s future API and other parts. In Play 2.1, with the move of Akka’s future API into Scala 2.10, Play started depending less directly on Akka. It gets all it’s execution contexts from Akka, and provides integration with Akka, … Read more
Creating an ActorSystem is very expensive, so you want to avoid creating a new one each time you need it. Also your actors should run in the same ActorSystem, unless there is a good reason for them not to. The name of the ActorSystem is also part the the path to the actors that run … Read more
There are three ways this can be achieved: 1. Post Materialization with SourceQueue You can use Source.queue that materializes the Flow into a SourceQueue: case class Weather(zipCode : String, temperature : Double, raining : Boolean) val bufferSize = 100 //if the buffer fills up then this strategy drops the oldest elements //upon the arrival of … Read more
The sender() will be different on the receiving end. Message sends using tell (also known as !): A tells message M to B. B tells that message to C. C thinks the sender() of message M is B. Message sends using forward: A tells message M to B. B forwards that message to C. C … Read more