Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

Posted by Michael Hunger on Mar 21, 2010

Sections

Architecture & Design,

Development

Topics

JAX-RS ,

AMQP ,

Scala ,

Java EE ,

Messaging ,

Akka ,

JVM Languages ,

Functional Programming ,

Web Services ,

Java ,

Languages ,

Concurrency ,

Enterprise Architecture ,

SOA ,

Programming ,

Architecture ,

Apache Camel ,

Actors ,

Comet

Share |

RELATED Research

Akka mountains in the north of Sweden,
from which the framework got its name.

Today, the Akka team released version 0.7 of their actors framework for the Java Virtual Machine.

The team around Jonas Bonér decided to address the future concurrency challenges instead of the current, shared state and lock based approaches on the JVM with a solution relying on message based actors, software transactional memory and appropriate fault handling strategies.

Akka's sources are available from github. It is Open Source and available under the Apache 2.0 License.

InfoQ talked to Jonas Bonér about the intent behind Akka, its current state and adoption, and future plans. His answers start the different sections covered here.

A Scalable Solution to the Concurrency Challenge

Q: What kind of problems does Akka address?

In my experience writing correct concurrent, scalable and fault-tolerant applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction. Akka is an attempt to change that, to simplify writing concurrent, scalable and highly available software for the JVM.

Q: Can you please tell us a bit about Akka's components and architecture?

Akka is using the Actor Model together with Software Transactional Memory (STM) to raise the abstraction level and provides a better platform to build correct concurrent and scalable applications. For fault-tolerance it adopts the "Let it crash" model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop. Akka also has Remote Actors and cluster support which provide for transparent distribution and the basis for truly scalable and fault-tolerant applications.

Akka's approach is a reimplementation of the actors paradigm that was initially presented by Carl Hewitt in 1973, and which has been sucessfully employed in languages like Erlang and in the telco industry where highly scalable systems with very high availability are common.

The actors approach is based solely on sending one-way (fire & forget), immutable messages to other actors and not sharing state at all. As actors don't have to be represented by threads and are very lightweight (about 600 bytes per actor) several million actors can be running on a commodity machine.

Error handling within the actors does not scale and is also not able to address the bigger picture. Thats why actors are supposed to die in the cause of failure and supervising actors are responsible for the fault handling of a group of actors linked to them. They are able to restart the failed actor or the whole group.

APIs and Usage

Q: How could I as a developer use Akka for my purposes?

You can use Akka for many different things and in many different ways. Deployment-wise you can for example use it as a library JAR and put it in WEB_INF/lib in your regular web application. Or you can run it as a stand-alone microkernel with one or many of its add-on modules (REST, Comet, Servlets, Persistence etc.).

Currently there is straightforward Scala API for creating actors, sending and receiving messages. Scala's case classes can be idiomatically applied as message types, so that immutability is guaranteed and pattern matching easily possible.

Here is a simplified example of using an actor:

case class Message(message: String)
class MyActor extends Actor {
  def receive = {
    case Message(s) => println("received message "+s)
    case _ =>      println("received unknown message")
  }
}
val myActor = new MyActor
myActor.start

myActor ! Message("test")

Actors can have different lifecycle methods. For supervision purposes linking actors, declaring Throwables that are acted upon and providing fault handlers with different restart strategies is supported.

A detailed example of using Akka to implement a scalable chat server is also available.

Java Integration

Integration with Java is supplied by an "Active Objects" approach. It uses AOP through AspectWerkz to turn regular POJOs into asynchronous non-blocking Active Objects with semantics of the Actor Model:

MyPOJO pojo = ActiveObject.newInstance(MyPOJO.class, 1000);

Non-void Methods are turned into "send-and-receive-eventually" semantics by asynchronously sending the message and wait on the reply using a Future. The immutability of the parameters has to be guaranteed by the sender as otherwise the actor model's semantics are broken. There is a configuration which deep clones all parameters that are neither primitives nor annotated as immutable.

Integration Modules

Q: How does Akka integrate with other infrastructures, libraries and tools?

Akka has excellent AMQP integration, JAX-RS integration for RESTful actors and Comet integration but in my view the most powerful and useful integration is the new Apache Camel integration that Martin Krasser has build. It allows Akka to integrate seamlessly and with almost no code with everything that Apache Camel supports.

Akka provides integration with different technologies with its modular architecture. A Microkernel module provides runtime operations. Persistence modules for Redis, MongoDB and Cassandra give fast, reliable storage. Integration aspects are handled with modules for Camel, REST, AMQP, Comet, Spring, Servlet, Guice and Lift.

Current release and development

Q: What are you planning for the future of this project?

In the short term we will support Scala 2.8, richer API for cluster membership and OSGi support. Long term we will have a distributed STM, JTA/XA support, more persistence back-ends (currently only Cassandra, Redis and MongoDB). We are currently in the process of starting up a business around Akka and will shortly be able to provide different levels of support packages and commercial add-on features such as management/monitoring and provisioning.

After the 0.6 release in January, this 0.7 release brings some very interesting features:

• Apache Camel integration
• Server-managed Remote Actors
• !!! function that returns a Future
• Clojure-style Agents
• Shoal cluster backend
• Redis-based transactional queue storage backend
• Distributed Comet
• Spring integration

Q: What kind of feedback have you gotten so far, who's using Akka right now?

We've seen a wide range of use-cases where Akka has been useful. There are companies in various domains such as gaming, betting, social networking, data mining/expert systems and finance that either have or will shortly deploy Akka in production. It's exciting times.

Thanks to Jonas for providing the Akka framework and for answering the questions

RelatedVendorContent

Introducing SQLFire: a memory-optimized, high performance SQL database

Early Access! Download JBoss Developer Studio 5.0 now, with packages for Mac, Windows or Linux!

App Server Evolution: REST, Cloud, and DevOps Support in Resin 4

Good Relationships: The Spring Data Neo4J Guide Book

Big Data, Cloud & Mobile: Navigate the New Development Reality with Resources from IBM

Related Sponsor

VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface

1. Back to top

   How close is it to be an "Erlang for Java"?

   by Raffaele Guidi

   Sorry if it is simplicistic, I mean "Erlang for java" as a summarization of:
   
   1 - Hot deployment
   2 - Transparent clustering
   3 - Dynamic clustering (i.e. hot addition of nodes to the cluster)

   Reply

2. Back to top

   Perhaps a little bit too simplistic

   by Peter Veentjer

   Hi Raffaele,
   
   1) What would be wrong with an erlang for Java? Erlang has very nice concepts but it doesn't run on a JVM (yet.. Erjang is being created)
   2) Akka supports much more than just actors to deal with concurrency. It also is possible to let actors access shared state using STM. Afaik Erlang has no support for STM.
   3) There is a lot of integration with all kinds of technologies going on in the Akka project.
   
   Peter Veentjer
   Founder of Multiverse: Software Transactional Memory for Java
   multiverse.codehaus.org

   Reply