Something else I picked up at Devoxx is Akka. I had heard of it before. Following a session about it renewed my interest.
Akka is a framework created to address problems in creating highly scalable and concurrent software. It is also the name of a mountain in Sweden and a Goddess.
Akka’s Keywords are: concurrency, scalability, fault-tolerance
Akka tries to address system overloads and is currently used in finance, telecom simulation, e-commerce and betting system. All applications that need a lot of event driven actions.
If you have heard of the Play framework, it will be using Akka internally from 2.0 on.
An Akka application uses Actors. What’s an actor: an object that encapsulates state and behaviour. Actors talk to each other as like they send mail. They don’t wait for each other. ( e.g. an actor could be every user in a mmorpg)
Some actor features:
- Your actors should extend Actor and override the receive method. That is the method that is used to receive messages.
- Akka takes care for sending the messages between the different actors. You don’t have to worry about it.
- In Akka they extended the java.util.concurrent.Future to make it non-blocking by adding onComplete, onResult, onException, onTimeout. And it adds functional methods like foreach, map, filter which are ideally for doing computations on your results. Actors can change there behavior at runtime.
- Actors can be remote, an actor can be bind to a name ( like with ejbs?). You can change your system from running in local mode to distributed mode at runtime.
- Actors can create actors. e.g. there can be a supervisor actor to handle errors. This actor can do restarts, create new actors and so on.
If you need a highly scalable way to communicate. Akka could be the thing you need. According to the stats that were shown the speed and request per seconds of the playframework improved a lot. I don’t remember the exact multiplier but it’s a huge improvement allowing Play! to achieve a very high request per second rate.