Thanks to some feedback was I finally in the position to write up a short piece about how to combine Specs2 with our TestKit. And to properly persist this piece of information, I added it to our docs, so please read more here.
I answered a question in the Akka mailinglist with example code that might be interesting if you need to do something similar. The use case is to perform a job consisting of a bunch of tasks. Delegate the tasks to worker actors, behind a router. Aggregate the results of workers and reply with one answer. Additionally, a worker should retry failed messages a few times, and then stop. If one worker terminates due to failure the whole job should be aborted.
Here is the example code:
The retry is implemented by forwarding the failing message to itself in preRestart. This places the message last in the mailbox, so ordering of messages is assumed to be unimportant for the processing of the tasks. Note that forward is necessary to retain the master as sender.
Workers are restarted in case of failure, and stopped after 2 restarts. This is handled by the supervisor of the worker routees, i.e. the router. A supervisorStrategy is specified when creating the router.
To be able to abort the whole job when one worker is stopped the master subscribe to termination, death watch, of the workers. References to the workers is obtained by sending a CurrentRoutees message to the router, which replies with RouterRoutees. context.watch(actorRef) initiates the death watch subscription. Terminated is delivered when a worker has been stopped.
When the master stops itself the children are also stopped, i.e. the router and its worker routees are stopped together with the master.
Aggregation is implemented by correlating the replies from the workers with a message id.
In my last post I said that configuring sbt-assembly to merge our beloved configuration files would not warrant its own plugin. Of course copy-pasting all that code would not have been really that nice either. What a pickle …
Following Mr. Holmes’ logic you will have guessed the solution: big kudos to Eugene for assisting with and merging my patch and releasing sbt-assembly version 0.8.0, which now does the right thing out of the box. It even is very easy to configure to merge other files, too (e.g. application.conf), just have a look at the project page linked above. And if all of that is not enough for your very special use-case, you can easily write your own strategy, which in best SBT tradition is documented here.
One of the things which changed in Akka 2.0 was the new configuration system, which is based upon the assumption that all used settings are defined in resources named “/reference.conf” and found on the classpath. This composes nicely, as then different libraries can coexist in the same project and the configuration systemjust works. One situation where this breaks, however, is when using fat jars for deployment. The problem usually shows up as
ConfigException$Missing: No configuration setting found for key: ‘akka.version’
and the cause is that during packaging of the fat jar only one of the many “reference.conf” files was copied instead of merging them all.
There was a discussion showing a solution when using proGuard, and I thought something similar should be possible using sbt-assembly. Eugene was so nice to add a hook which allows this to work, based on this ticket, so here it goes.
The following of course assumes that the sbt-assembly plugin has been installed in version 0.7.4, for which the following addition is needed:
Then the code to make SBT do the right thing is so little that it does not warrant its own plugin (it only looks long because this blog’s style is like literally writing on the margins of a newpaper):
Making the location of the merged “reference.conf” configurable or merging other things is left as an exercise to the reader.
As a bonus, this adds a “merge-reference” task which you can invoke to perform the merge and show the location:
> show merge-reference
[info] reference.conf
[video]
50 million messages per second on a single machine is mind blowing!
We have measured this for a micro benchmark of Akka 2.0.
As promised in Scalability of Fork Join Pool I will here describe one of the tuning settings that can be used to achieve even higher throughput than the amazing numbers presented previously. Using the same benchmark as in Scalability of Fork Join Pool and only changing the configuration we go from 20 to 50 million messages per second.
The micro benchmark use pairs of actors sending messages to each other, classical ping-pong. All sharing the same fork join dispatcher.
Hardware and configuration:
Here is the result of using different values for the throughput setting of the dispatcher. 5 is the default value. The test was run with 96 actors and each test result was based on at least 15 seconds of execution time (960 million messages), long warmup excluded.
As you see the number of processed messages per second increase dramatically with increased throughput configuration setting up to 20.
When using even higher throughput values the curve becomes more flat, but with a maximum above 50 million messages per second.
What is the magic behind the throughput setting?
It configures how many messages an actor should process in a batch. For example throughput=20 means that once the dispatcher schedules a thread for the actor it will continue to process 20 messages, if the mailbox isn’t empty, before returning the thread to the pool.
The trade-off is that other actors that use the same dispatcher might have to wait longer before they get a chance to run, i.e. you trade higher throughput for increased latency. It is the classic tradeoff of throughput vs fairness. The optimal value depends on your use case, e.g. how long the message processing time is.
A related configuration setting is throughput-deadline-time, which defines how long time the actor is allowed to continue to process messages from the mailbox before the thread is returned to the pool.
Finally, let’s take a look at how the message throughput (msg/s) scales with number of actors when using throughput configuration value 200.
As you can see, we now get more than 50 million messages per second. Not bad at all. Download Akka 2.0 yourself and give her a spin.
Happy hAkking.
Kindle version of the latest Akka docs: http://download.akka.io/downloads/akka-2.1-SNAPSHOT.mobi
Enjoy.
We are proud to announce that Typesafe Stack 2.0 have been released.
Some of the highlights are:
Found out more about the details on Akka News.
We are very proud to announce that Akka received an honorable mention in the Third Party Libraries category in the Dr Dobb’s Jolt Awards 2012.
Read more here: http://drdobbs.com/joltawards/232601043?pgno=2
This is another topic which comes up from time to time on the mailing list: typed actors are “nice”, but some things work differently or not at all, so what exactly are they good for?
Philosophy
As a little historical side-note, typed actors in Akka 1.x were implemented using runtime byte-code generation by the AspectWerkz library, which is no longer actively maintained. Thus, Viktor re-wrote them based on JDK proxies, while integrating them more smoothly with the rest of Akka. In version 2.0, typed actors are free of external dependencies and part of the core module “akka-actor”. They can send and receive messages like normal actors, be supervised by normal actors and supervise normal actors, they can intercept life-cycle monitoring messages and take part in the EventStream, but all of this does not come quite as naturally as for the normal untyped actors. The reason is that typed actors do not ideally model what actors are: entities which process an incoming stream of messages with their behavior, changing their state in response and generating other messages. The simplicity of this model is what enables perfect encapsulation in a truly object-oriented way and it enables the location transparency and fault tolerance of actor systems.
But typed actors do have their place, as hybrids between POJO and Actor: exactly at the touching point where actor systems meet non-actor code. Communication between actors means placing message objects into the recipient’s mailbox, which is not easily done if the receiver shall be a plain Java object. A typed actor is a normal actor wrapped in a given interface, responding to method calls instead of message sends.
A Simple Example
The Service is represented by a simplified interface, which is implemented by an inconspicuous class ServiceImpl. The vigilant reader will have noticed that the special magic enters on line 18 by way of TypedActor.context, that returns the ActorContext of the untyped actor which will be wrapping this implementation. The next line then demonstrates the creation of the child actor which will be servicing the requests. Notice how the asynchronous nature of actor communication is retained by returning a Future for sending the (eventual) reply back to the requesting party.
The only noteworthy action with respect to typed actors is shown on lines 38ff, where the typed actor is instantiated. Declaring a normal actor and handling Future callbacks is assumed prerequisite knowledge for this post.
What else can you do?
What you just witnessed is the basic principle of wrapping a function implemented by an actor system into an interface which can be consumed by “normal” non-actor code. This should be enough to get going, but you will probably at some point want to learn about the various additional traits: Supervisor, Receiver (for receiving normal messages), life-cycle callbacks PreStart, PreRestart, PostRestart and PostStop.
What should you NOT do?
Most importantly, use them sparingly: untyped actors make the actor model more explicit, which will benefit your application design. That said, in those cases where a typed actor is preferable (for example as shown above), only declare methods which return either Unit (i.e. «void») or a Future. All other possibilities lead to blocking behavior when sending an invocation to the actor, and parking one thread only to wake up another is not a good idea. Also, making the reply (if any) asynchronous enables you to distribute your application across multiple network nodes without running into the RPC troubles.
And above all: never send a «this» reference to anybody, which includes arguments to method invocations on different objects. If you for example register the typed actor implementation for a callback, that callback will be executed concurrently to the typed actor itself and in a different context, leading to all those pesky locking problems which you wanted to rid yourself of by using Akka. If you must send around something which represents the typed actor, always use «TypedActor.self».