Jonas Bonér

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

2010-01-04T00:00:00+01:00

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

4 Jan 2010

Introduction

Writing correct concurrent, fault-tolerant and scalable 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.

Akka uses the Actor Model together with Software Transactional Memory to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.

For fault-tolerance Akka adopts the “Let it crash”, also called “Embrace failure”, model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop.

Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.

Akka is Open Source and available under the Apache 2 License.

In this article we will introduce you to Akka and see how we can utilize it to build a highly concurrent, scalable and fault-tolerant network server.

But first let’s take a step back and discuss what Actors really are and what they are useful for.

Actors

The Actor Model provides a higher level of abstraction for writing concurrent and distributed systems. It alleviates the developer from having to deal with explicit locking and thread management. It makes it easier to write correct concurrent and parallel systems. Actors are really nothing new, they were defined in the 1963 paper by Carl Hewitt and have been popularized by the Erlang language which emerged in the mid 80s. It has been used by for example at Ericsson with great success to build highly concurrent and extremely reliable (99.9999999 % availability – 31 ms/year downtime) telecom systems.

Actors encapsulates state and behavior into a lightweight process/thread. In a sense they are like OO objects but with a major semantic difference; they do not share state with any other Actor. Each Actor have their own view of the world and can only have impact on other Actors by sending messages to them. Messages are sent asynchronously and non-blocking in a so-called “fire-and-forget” manner where the Actor sends off a message to some other Actor and then do not wait for a reply but goes off doing other things or are suspended by the runtime. Each Actor has a mailbox (ordered message queue) in which incoming messages are processed one by one. Since all processing is done asynchronously and Actors do not block and consume any resources while waiting for messages, Actors tend to give very good concurrency and scalability characteristics and are excellent for building event-based systems.

Creating Actors

Akka has both a Scala API and a Java API. In this article we will only look at the Scala API since that is the most expressive one. The article assumes some basic Scala knowledge, but even if you don’t know Scala I don’t think it will not be too hard to follow along anyway.

Akka has adopted the same style of writing Actors as Erlang in which each Actor has an explicit message handler which does pattern matching to match on the incoming messages.

Actors can be created either by:

Extending the ‘Actor’ class and implementing the ‘receive’ method.
Create an anonymous Actor using one of the ‘actor’ methods.

Here is a little example before we dive into a more interesting one.

class MyActor extends Actor {
  def receive = {
    case "test" => println("received test")
    case _ =>      println("received unknown message")
  }
}

val myActor = new MyActor
myActor.start

Here is the same Actor with the anonymous syntax. Anonymous Actors are implicitly started:

val myActor = actor { 
  case "test" => println("received test")
  case _ =>      println("received unknown message")
}

Akka Actors are extremely lightweight. Each Actor consume ~600 bytes, which means that you can create 6.5 million on 4 G RAM.

Messages are sent using the ‘!’ operator:

myActor ! "test"

Sample application

We will try to write a simple chat/IM system. It is client-server based and uses remote Actors to implement remote clients. Even if it is not likely that you will ever write a chat system I think that it can be a useful exercise since it uses patterns and idioms found in many other use-cases and domains.

We will use many of the features of Akka along the way. In particular; Actors, fault-tolerance using Actor supervision, remote Actors, Software Transactional Memory (STM) and persistence.

But let’s start by defining the messages that will flow in our system.

Creating messages

It is very important that all messages that will be sent around in the system are immutable. The Actor model relies on the simple fact that no state is shared between Actors and the only way to guarantee that is to make sure we don’t pass mutable state around as part of the messages.

In Scala we have something called case classes. These make excellent messages since they are both immutable and great to pattern match on.

Let’s now start by creating the messages that will flow in our system.

/**
 * ChatServer's internal events.
 */
sealed trait Event

case class Login(username: String) extends Event
case class Logout(username: String) extends Event

case class ChatMessage(fromUser: String, message: String) extends Event

case class GetChatLog(fromUser: String) extends Event
case class ChatLog(messages: List[String]) extends Event

As you can see with these messages we can log in and out, send a chat message and ask for and get a reply with all the messages in the chat log so far.

Client: Sending messages

Our client wraps each message send in a function, making it a bit easier to use. Here we assume that we have a reference to the chat service so we can communicate with it by sending messages. Messages are sent with the ‘!’ operator (pronounced “bang”). This sends a message of asynchronously and do not wait for a reply.

Sometimes however, there is a need for sequential logic, sending a message and wait for the reply before doing anything else. In Akka we can achieve that using the ‘!!’ (“bangbang”) operator. When sending a message with ‘!!’ we do not return immediately but wait for a reply using a Future. A ‘Future’ is a promise that we will get a result later but with the difference from regular method dispatch that the OS thread we are running on is put to sleep while waiting and that we can set a time-out for how long we wait before bailing out, retrying or doing something else. The ‘!!’ function returns a scala.Option which implements the Null Object pattern. It has two subclasses; ‘None’ which means no result and ‘Some(value)’ which means that we got a reply. The ‘Option’ class has a lot of great methods to work with the case of not getting a defined result. F.e. as you can see below we are using the ‘getOrElse’ method which will try to return the result and if there is no result defined invoke the “…OrElse” statement.

/**
 * Chat client.
 */
class ChatClient(val name: String) { 
  import Actor.Sender.Self
  def login =                 ChatService ! Login(name) 
  def logout =                ChatService ! Logout(name)  
  def post(message: String) = ChatService ! ChatMessage(name, name + ": " + message)  
  def chatLog: ChatLog = {
    val option = ChatService !! (GetChatLog(name), 1000) // timeout 1000 ms
    option.getOrElse(throw new Exception("Couldn't get the chat log"))	
  }
}

Session: Receiving messages

Now we are done with the client side and let’s dig into the server code. We start by creating a user session. The session is an Actor and is defined by extending the ‘Actor’ trait. This trait has one abstract method that we have to define; ‘receive’ which implements the message handler for the Actor.

In our example the session has state in the form of a ‘List’ with all the messages sent by the user during the session. In takes two parameters in its constructor; the user name and a reference to an Actor implementing the persistent message storage. For both of the messages it responds to, ‘ChatMessage’ and ‘GetChatLog’, it passes them on to the storage Actor.

If you look closely (in the code below) you will see that when passing on the ‘GetChatLog’ message we are not using ‘!’ but ‘forward’. This is similar to ‘!’ but with the important difference that it passes the original sender reference, in this case to the storage Actor. This means that the storage can use this reference to reply to the original sender (our client) directly.

/**
 * Internal chat client session.
 */
class Session(user: String, storage: Actor) extends Actor {
  private val loginTime = System.currentTimeMillis
  private var userLog: List[String] = Nil

  log.info("New session for user [%s] has been created at [%s]", user, loginTime)

  def receive = {
    case event: ChatMessage => 
      userLog ::= event.message
      storage ! event

    case event: GetChatLog => 
      storage forward event
  }
}

Let it crash: Implementing fault-tolerance

Akka’s approach to fault-tolerance; the “let it crash” model, is implemented by linking Actors. It is very different to what Java and most non-concurrency oriented languages/frameworks have adopted. It’s a way of dealing with failure that is designed for concurrent and distributed systems.

If we look at concurrency first. Now let’s assume we are using non-linked Actors. Throwing an exception in concurrent code, will just simply blow up the thread that currently executes the Actor. There is no way to find out that things went wrong (apart from see the stack trace in the log). There is nothing you can do about it. Here linked Actors provide a clean way of both getting notification of the error so you know what happened, as well as the Actor that crashed, so you can do something about it.

Linking Actors allow you to create sets of Actors where you can be sure that either:

All are dead
All are alive

This is very useful when you have hundreds of thousands of concurrent Actors. Some Actors might have implicit dependencies and together implement a service, computation, user session etc. for these being able to group them is very nice.

Akka encourages non-defensive programming. Don’t try to prevent things from go wrong, because they will, whether you want it or not. Instead; expect failure as a natural state in the life-cycle of your app, crash early and let someone else (that sees the whole picture), deal with it.

Now let’s look at distributed Actors. As you probably know, you can’t build a fault-tolerant system with just one single node, but you need at least two. Also, you (usually) need to know if one node is down and/or the service you are talking to on the other node is down. Here Actor supervision/linking is a critical tool for not only monitoring the health of remote services, but to actually manage the service, do something about the problem if the Actor or node is down. This could be restarting him on the same node or on another node.

To sum things up, it is a very different way of thinking but a way that is very useful (if not critical) to building fault-tolerant highly concurrent and distributed applications.

Supervisor hierarchies

A supervisor is a regular Actor that is responsible for starting, stopping and monitoring its child Actors. The basic idea of a supervisor is that it should keep its child Actors alive by restarting them when necessary. This makes for a completely different view on how to write fault-tolerant servers. Instead of trying all things possible to prevent an error from happening, this approach embraces failure. It shifts the view to look at errors as something natural and something that will happen and instead of trying to prevent it; embrace it. Just “let it crash” and reset the service to a stable state through restart.

Akka has two different restart strategies; All-For-One and One-For-One.

OneForOne: Restart only the component that has crashed.
AllForOne: Restart all the components that the supervisor is managing, including the one that have crashed.

The latter strategy should be used when you have a certain set of components that are coupled in some way that if one is crashing they all need to be reset to a stable state before continuing.

Chat server: Supervision, Traits and more

There are two ways you can define an Actor to be a supervisor; declaratively and dynamically. In this example we use the dynamic approach. There are two things we have to do:

Define the fault handler by setting the ‘faultHandler’ member field to the strategy we want.
Define the exceptions we want to “trap”, e.g. which exceptions should be handled according to the fault handling strategy we have defined. This in done by setting the ‘trapExit’ member field to a ‘List’ with all exceptions we want to trap.

The last thing we have to do to supervise Actors (in our example the storage Actor) is to ‘link’ the Actor. Invoking ‘link(actor)’ will create a link between the Actor passed as argument into ‘link’ and ourselves. This means that we will now get a notification if the linked Actor is crashing and if the cause of the crash, the exception, matches one of the exceptions in our ‘trapExit’ list then the crashed Actor is restarted according the the fault handling strategy defined in our ‘faultHandler’. We also have the ‘unlink(actor)’ function which disconnects the linked Actor from the supervisor.

In our example we are using a method called ‘startLink(actor)’ which starts the Actor and links him in an atomic operation. The linking and unlinking is done in ‘init’ and ‘shutdown’ callback methods which are invoked by the runtime when the Actor is started and shut down (shutting down is done by invoking ‘actor.stop’). In these methods we initialize our Actor, by starting and linking the storage Actor and clean up after ourselves by shutting down all the user session Actors and the storage Actor.

That is it. Now we have implemented the supervising part of the fault-tolerance for the storage Actor. But before we dive into the ‘ChatServer’ code there are some more things worth mentioning about its implementation.

It defines an abstract member field holding the ‘ChatStorage’ implementation the server wants to use. We do not define that in the ‘ChatServer’ directly since we want to decouple it from the actual storage implementation.

The ‘ChatServer’ is a ‘trait’, which is Scala’s version of mixins. A mixin can be seen as an interface with an implementation and is a very powerful tool in Object-Oriented design that makes it possible to design the system into small, reusable, highly cohesive, loosely coupled parts that can be composed into larger object and components structures.

I’ll try to show you how we can make use Scala’s mixins to decouple the Actor implementation from the business logic of managing the user sessions, routing the chat messages and storing them in the persistent storage. Each of these separate parts of the server logic will be represented by its own trait; giving us four different isolated mixins; ‘Actor’, ‘SessionManagement’, ‘ChatManagement’ and ‘ChatStorageFactory’ This will give us as loosely coupled system with high cohesion and reusability. At the end of the article I’ll show you how you can compose these mixins into a the complete runtime component we like.

/**
 * Chat server. Manages sessions and redirects all 
 * other messages to the Session for the client.
 */
trait ChatServer extends Actor {
  faultHandler = Some(OneForOneStrategy(5, 5000))
  trapExit = List(classOf[Exception])

  val storage: ChatStorage

  log.info("Chat service is starting up...")

  // actor message handler
  def receive = sessionManagement orElse chatManagement

  // abstract methods to be defined somewhere else
  protected def chatManagement: PartialFunction[Any, Unit]
  protected def sessionManagement: PartialFunction[Any, Unit]   
  protected def shutdownSessions: Unit

  override def init = startLink(storage)

  override def shutdown = { 
    log.info("Chat server is shutting down...")
    shutdownSessions
    unlink(storage)
    storage.stop
  }
}

If you look at the ‘receive’ message handler function you can see that we have defined it but instead of adding our logic there we are delegating to two different functions; ‘sessionManagement’ and ‘chatManagement’, chaining them with ‘orElse’. These two functions are defined as abstract in our ‘ChatServer’ which means that they have to be provided by some another mixin or class when we instantiate our ‘ChatServer’. Naturally we will put the ‘sessionManagement’ implementation in the ‘SessionManagement’ trait and the ‘chatManagement’ implementation in the ‘ChatManagement’ trait. First let’s create the ‘SessionManagement’ trait.

Chaining partial functions like this is a great way of composing functionality in Actors. You can for example put define one default message handle handling generic messages in the base Actor and then let deriving Actors extend that functionality by defining additional message handlers. There is a section on how that is done here.

Session management

The session management is defined in the ‘SessionManagement’ trait in which we implement the two abstract methods in the ‘ChatServer’; ‘sessionManagement’ and ‘shutdownSessions’.

The ‘SessionManagement’ trait holds a ‘HashMap’ with all the session Actors mapped by user name as well as a reference to the storage (to be able to pass it in to each newly created ‘Session’).

The ‘sessionManagement’ function performs session management by responding to the ‘Login’ and ‘Logout’ messages. For each ‘Login’ message it creates a new ‘Session’ Actor, starts it and puts it in the ‘sessions’ Map and for each ‘Logout’ message it does the opposite; shuts down the user’s session and removes it from the ‘sessions’ Map.

The ‘shutdownSessions’ function simply shuts all the sessions Actors down. That completes the user session management.

/**
 * Implements user session management.
 * <p/>
 * Uses self-type annotation 'this: Actor =>'
 * to declare that it needs to be mixed in with an Actor.
 */
trait SessionManagement { this: Actor => 

  val storage: ChatStorage // needs someone to provide the ChatStorage
  val sessions = new HashMap[String, Actor]

  protected def sessionManagement: PartialFunction[Any, Unit] = {
    case Login(username) => 
      log.info("User [%s] has logged in", username)
      val session = new Session(username, storage)
      session.start
      sessions += (username -> session)

    case Logout(username) =>        
      log.info("User [%s] has logged out", username)
      val session = sessions(username)
      session.stop
      sessions -= username 
  }  

  protected def shutdownSessions = 
    sessions.foreach { case (_, session) => session.stop }  
}

Chat message management

Chat message management is implemented by the ‘ChatManagement’ trait. It has an abstract ‘HashMap’ session member field with all the sessions. Since it is abstract it needs to be mixed in with someone that can provide this reference. If this dependency is not resolved when composing the final component, you will get a compilation error.

It implements the ‘chatManagement’ function which responds to two different messages; ‘ChatMessage’ and ‘GetChatLog’. It simply gets the session for the user (the sender of the message) and routes the message to this session. Here we also use the ‘forward’ function to make sure the original sender reference is passed along to allow the end receiver to reply back directly.

/**
 * Implements chat management, e.g. chat message dispatch.
 * <p/>
 * Uses self-type annotation 'this: Actor =>'
 * to declare that it needs to be mixed in with an Actor.
 */
trait ChatManagement { this: Actor =>
  val sessions: HashMap[String, Actor] // someone needs to provide the Session map

  protected def chatManagement: PartialFunction[Any, Unit] = {
    case msg @ ChatMessage(from, _) => sessions(from) ! msg
    case msg @ GetChatLog(from) =>     sessions(from) forward msg
  }
}

Using an Actor as a message broker, as in this example, is a very common pattern with many variations; load-balancing, master/worker, map/reduce, replication, logging etc. It becomes even more useful with remote Actors when we can use it to route messages to different nodes.

STM and Transactors

Actors are excellent for solving problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing. This model fits many problems. But the Actor model is unfortunately a terrible model for implementing truly shared state. E.g. when you need to have consensus and a stable view of state across many components. The classic example is the bank account where clients can deposit and withdraw, in which each operation needs to be atomic. For detailed discussion on the topic see this presentation.

Software Transactional Memory (STM) on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM are that transactions compose and that it raises the abstraction level from lock-based concurrency.

Akka has a STM implementation that is based on the same ideas as found in the Clojure language; Managed References working with immutable data.

Akka allows you to combine Actors and STM into what we call Transactors (short for Transactional Actors), these allow you to optionally combine Actors and STM provides IMHO the best of the Actor model (simple concurrency and asynchronous event-based programming) and STM (compositional transactional shared state) by providing transactional, compositional, asynchronous, event-based message flows. You don’t need Transactors all the time but when you do need them then you really need them.

Akka currently provides three different transactional abstractions; ‘Map’, ‘Vector’ and ‘Ref’. They can be shared between multiple Actors and they are managed by the STM. You are not allowed to modify them outside a transaction, if you do so, an exception will be thrown.

What you get is transactional memory in which multiple Actors are allowed to read and write to the same memory concurrently and if there is a clash between two transactions then both of them are aborted and retried. Aborting a transaction means that the memory is rolled back to the state it were in when the transaction was started.

In database terms STM gives you ‘ACI’ semantics; ‘Atomicity’, ‘Consistency’ and ‘Isolation’. The ‘D’ in ‘ACID’; ‘Durability’, you can’t get with an STM since it is in memory. This however is addressed by the persistence module in Akka.

Persistence: Storing the chat log

Akka provides the possibility of taking the transactional data structures we discussed above and making them persistent. It is an extension to the STM which guarantees that it has the same semantics.

The persistence module has pluggable storage back-ends. At the time of the writing it has three different storage back-ends:

Cassandra – A distributed structured storage database.
MongoDB – A high performance schema-free, document oriented data store with SQL like query facilities.
Redis – An advanced key-value store, also called a data structure server, with lists, ordered sets etc.

They all implement persistent ‘Map’, ‘Vector’ and ‘Ref’. Which can be created and retrieved by id through one of the storage modules.

val map =    RedisStorage.newMap(id)
val vector = CassandraStorage.newVector(id)
val ref =    MongoStorage.newRef(id)

Chat storage: Backed by Redis

Now let’s implement the persistent storage. We start by creating a ‘ChatStorage’ trait allowing us to have multiple different storage backend. For example one in-memory and one persistent.

/**
 * Abstraction of chat storage holding the chat log.
 */
trait ChatStorage extends Actor

Let’s use Redis to implementation the persistent storage. Redis is an excellent storage backend, blazingly fast with a rich data model.

Our ‘RedisChatStorage’ extends the ‘ChatStorage’ trait. The only state it holds is the ‘chatLog’ which is a ‘Vector’ managed by Redis. We give it an explicit id (the String “akka.chat.log”) to be able to retrieve the same vector across remote nodes and/or through server restarts.

It responds to two different messages; ‘ChatMessage’ and ‘GetChatLog’. The ‘ChatMessage’ message handler takes the ‘message’ attribute and appends it to the ‘chatLog’ vector. Here you can see that we are using the ‘atomic { … }’ block to run the vector operation in a transaction. Redis works with binary data so we need to convert the message into a binary representation. Since we are using Strings we just have to invoke ‘message.getBytes(“UTF-8”)’, but if we would have had a richer message that we wanted to persist then we would have had to use one of the Akka’s serialization traits or serializers. You can read more about that here.

The ‘GetChatLog’ message handler retrieves all the messages in the chat log storage inside an atomic block, iterates over them using the ‘map’ combinator transforming them from ‘Array[Byte] to ’String’. Then it invokes the ‘reply(message)’ function that will send the chat log to the original sender; the ‘ChatClient’.

You might rememeber that the ‘ChatServer’ was supervising the ‘ChatStorage’ actor. When we discussed that we showed you the supervising Actor’s view. Now is the time for the supervised Actor’s side of things. First, a supervised Actor need to define a life-cycle in which it declares if it should be seen as a:

‘Permanent’: which means that the actor will always be restarted.
‘Temporary’: which means that the actor will not be restarted, but it will be shut down through the regular shutdown process so the ‘shutdown’ callback function will called.

We define the ‘RedisChatStorage’ as ‘Permanent’ by setting the ‘lifeCycle’ member field to ‘Some(LifeCycle(Permanent))’.

The idea with this crash early style of designing your system is that the services should just crash and then they should be restarted and reset into a stable state and continue from there. The definition of “stable state” is domain specific and up to the application developer to define. Akka provides two callback functions; ‘preRestart’ and ‘postRestart’ that are called right before and right after the Actor is restarted. Both of these functions take a ‘Throwable’, the reason for the crash, as argument. In our case we just need to implement the ‘postRestart’ hook and there re-initialize the ‘chatLog’ member field with a fresh persistent ‘Vector’ from Redis.

/**
 * Redis-backed chat storage implementation.
 */
class RedisChatStorage extends ChatStorage {
  lifeCycle = Some(LifeCycle(Permanent))    

  private var chatLog = RedisStorage.getVector("akka.chat.log")

  log.info("Redis-based chat storage is starting up...")

  def receive = {
    case msg @ ChatMessage(from, message) => 
      log.debug("New chat message [%s]", message)
      atomic { 
        chatLog + message.getBytes("UTF-8")
      }

    case GetChatLog(_) => 
      val messageList = atomic {
       chatLog.map(bytes => new String(bytes, "UTF-8")).toList
      }
      reply(ChatLog(messageList))
  }

  override def postRestart(reason: Throwable) = 
    chatLog = RedisStorage.getVector("akka.chat.log")  
}

The last thing we need to do in terms of persistence is to create a ‘RedisChatStorageFactory’ that will take care of instantiating and resolving the ‘val storage: ChatStorage’ field in the ‘ChatServer’ with a concrete implementation of our persistence Actor.

/**
 * Creates and a RedisChatStorage.
 */
trait RedisChatStorageFactory {
  val storage: ChatStorage = new RedisChatStorage
}

Composing the full Chat Service

We have now created the full functionality for the chat server, all nicely decoupled into isolated and well-defined traits. Now let’s bring all these traits together and compose the complete concrete ‘ChatService’.

/**
 * Object encapsulating the full Chat Service.
 */
object ChatService extends 
  ChatServer with 
  SessionManagement with 
  ChatManagement with 
  RedisChatStorageFactory

Making the ChatService remote

Now that we have the ‘ChatService’ object how do we make it into a remote service that we can use from different nodes?

It is very simple. We only need to do two things. First we need to start up a remote server to run the ‘ChatService’. Then for each client that wants to use the ‘ChatService’ we just need to invoke ‘ChatService.makeRemote’ to get a handle to the remote ‘ChatService’.

Starting the first step. We have two options on how we can start up a remote server. Either start up the ‘RemoteNode’ in some part of the code that runs on the machine you want to run the server on (can just be a simple class with a ‘main’ method).

We start the ‘RemoteNode’ by invoking ‘start’ and passing in the host name and port.

RemoteNode.start("darkstar", 9999)

You can also choose to use the version of ‘start’ that takes a ‘ClassLoader’ as argument if you want to be explicit on through which class loader you want to load the class of the Actor that you want to run as remote service.

The second option is to put your application in a JAR file and drop it into the ‘AKKA_HOME/deploy’ directory and then start up the Akka microkernel. This will deploy your application and start the ‘RemoteNode’ for you. Then you use the ‘AKKA_HOME/config/akka.conf’ configuration file to configure the remote server (among many other things). The microkernel is started up like this:

export AKKA_HOME=...
cd $AKKA_HOME
java -jar $AKKA_HOME/dist/akka-0.6.jar

That was the server part. The client part is just as simple. We only need to tell the runtime system that we want to use the ‘ChatService’ as a remote Actor by invoking the ‘makeRemote(hostname, port)’ function on it. This will instantiate the Actor on the remote host and turn the local Actor instance into a proxy or handle through which we can use the remote Actor transparently with the exact same semantics as if it was a regular local Actor.

That’s it. Now let’s run a sample client session.

ChatService.makeRemote("darkstar", 9999)
ChatService.start

That’s it. Were done. Now we have a, very simple, but scalable, fault-tolerant, event-driven, persistent chat server that can without problem serve a million concurrent users on a regular workstation.

Let’s use it.

Sample client chat session

Now let’s create a simple test runner that logs in posts some messages and logs out.

import se.scalablesolutions.akka.sample.chat._

/**
 * Test runner emulating a chat session.
 */
object Runner {
  // create a handle to the remote ChatService 
  ChatService.makeRemote("localhost", 9999)
  ChatService.start

  def run = {
    val client = new ChatClient("jonas")

    client.login

    client.post("Hi there")
    println("CHAT LOG:\n\t" + client.chatLog.log.mkString("\n\t"))

    client.post("Hi again")
    println("CHAT LOG:\n\t" + client.chatLog.log.mkString("\n\t"))

    client.logout
  }
}

Sample code

All this code is available as part of the Akka distribution. It resides in the ‘./akka-samples/akka-sample-chat’ module and have a ‘README’ file explaining how to run it as well as a Maven ‘pom.xml’ build file so it is easy to build, run, hack, rebuild, run etc. You can also just read the next section for instructions on how to run it.

Or if you rather browse it online.

Run it

First we need to start up Redis.

Download Redis from here.
Step into the distribution.
Build: ‘make install’.
Run: ‘./redis-server’.

For details on how to set up Redis server have a look here.

Download and build Akka

Download Akka from http://github.com/jboner/akka/downloads.
Set ‘AKKA_HOME’ environment variable to the root of the Akka distribution.
Open up a shell and step into the Akka distribution root folder.
Build Akka by invoking ‘mvn install -Dmaven.test.skip=true’. This will also bulid the sample application and deploy it to the ‘$AKKA_HOME/deploy’ directory.

Run the microkernel

export AKKA_HOME=...
cd $AKKA_HOME
java -jar ./dist/akka-0.6.jar

Run a sample chat session

Now start up a new shell and go down into the ‘./akka-samples/akka-sample-chat’ directory.
Invoke ‘mvn scala:console -o’. This will give you a Scala REPL (interpreter) with the chat application and all its dependency JARs on the classpath.
Simply paste in the whole code block with the ‘Runner’ object above and invoke ‘Runner.run’. This run a simulated client session that will connect to the running server in the microkernel.
Invoke ‘Runner.run’ again and again…

Now you could test client reconnect by killing the running microkernel and start it up again. See the client reconnect take place in the REPL shell.

That’s it. Have fun.

Onward

There is much much more to Akka than what we have covered in this article. For example Active Objects, Cluster Membership API, a Comet module, REST (JAX-RS) integration, a Security module, AMQP integration, Spring integration, Google Guice integration, Lift integration, a rich Transaction API, tons of configuration possibilities etc.

Asynchronous Event Sourcing using Actors

2009-02-12T00:00:00+01:00

Asynchronous Event Sourcing using Actors

12 Feb 2009

Introduction

There has been some discussions lately about Event Sourcing. For example, Greg Young recently discussed how they were using Event Sourcing and explicit state transitions together with Domain-Driven Design (DDD) to build a highly scalable and loosely coupled system.

So what is Event Sourcing? Martin Fowler wrote an excellent article about some years ago and there is no use repeating it here, so please read (or at least skim) that article before reading further.

What I will do in this article is to show you how you can implement Event Sourcing using asynchronous message-passing based on actors. Actors are generally an excellent paradigm to implement asynchronous event-based systems and they allow you to easily get explicit state transitions working nicely together with an immutable domain model. This gives a concurrent system that scales very well, with the side-effect/feature of Eventual Consistency.

Domain model

I will reuse the example Martin Fowler used in his article but rewrite it using Scala Actors. So without further ado let’s start hacking. Martin’s example implements a simple Ship management system.

First, let’s define the simplistic domain model; Ship, Port and Country.

The Ship class is worth discussing a bit. It is an actor, which means that it is an isolated ‘lightweight process’ with its own state, which is only accessible and modifiable using messages (in our case, events). The Ship actor responds to four different events; set arrival and departure, query for current port and finally reset the state.

class Ship(val name: String, val home: Port) extends Actor {

  def act = loop(home)

  private def loop(current: Port) {
    react {
      case ArrivalEvent(time, port, _) => 
        println(toString + " ARRIVED  at port   " + port + " @ " + time)
        loop(port)

      case DepartureEvent(time, port, _) => 
        println(toString + " DEPARTED from port " + port  + " @ " + time)
        loop(Port.AT_SEA)

      case Reset => 
        println(toString + " has been reset")
        loop(home)

      case CurrentPort => 
        reply(current)
        loop(current)

      case unknown => 
        error("Unknown event: " + unknown)
    }
  }

  override def toString = "Ship(" + name + ")"
}

class Port(val city: String, val country: Country) {
  override def toString = "Port(" + city + ")"  
}
object Port {
  val AT_SEA = new Port("AT SEA", Country.AT_SEA)
}

case class Country(val name: String)
object Country {
  val US = new Country("US")
  val CANADA = new Country("CANADA")
  val AT_SEA = new Country("AT_SEA")
}

Note: In this example I have been managing the state in the actors (Ship and EventProcessor) by passing it on in the recursive ‘loop’, using stack-confinement. This is a slick technique but not possible if you need to persist the state in some way, either using something like Terracotta or store it in a database. Then you would have to put the state in private field(s) in the actor, something that will not affect the correctness or performance.

Events

Now let’s define our events, implementing the explicit state transitions DepartureEvent and ArrivalEvent. In Scala these are best defined as ‘case classes’ which supports pattern matching and attribute destructing. These two events encapsulate their state transition in the ‘process’ method. We also define one event for asking the Ship for its current port and one for resetting its state to its “home” port.

sealed abstract case class Event

abstract case class StateTransitionEvent(val occurred: Date) 
  extends Event {
  val recorded = new Date
  def process: Unit
}

case class DepartureEvent(val time: Date, val port: Port, val ship: Ship) 
  extends StateTransitionEvent(time) {
  override def process = ship ! this
}

case class ArrivalEvent(val time: Date, val port: Port, val ship: Ship) 
  extends StateTransitionEvent(time) {
  override def process = ship ! this
}

case object Reset extends Event

case object CurrentPort extends Event

Event processor

Finally, let’s define the event processor. This class is an actor which responds to any event that is a subtype of StateTransitionEvent, e.g. either DepartureEvent or ArrivalEvent. It also holds a history list (‘log’) with all events that it has processed. Something that we will make use of later on.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[StateTransitionEvent]) {
    react {
      case event: StateTransitionEvent => 
        event.process
        loop(event :: log)

      case unknown => 
        error("Unknown event: " + unknown)
    }
  }
}

Test run 1

Now we have the basis for our Ship Management Event Sourcing framework. Let’s create some tests to drive the thing. Since each event submission is processed asynchronously we have to interleave them with calls to ‘Thread.sleep(500)’ in order to see what is going on.

class ActorBasedEventSourcingTest {

  private var shipKR: Ship = _
  private var portSFO, portLA, portYYV: Port = _
  private var processor: EventProcessor = _

  def setup = {
    processor = new EventProcessor
    processor.start
    
    portSFO = new Port("San Francisco", Country.US)
    portLA = new Port("Los Angeles", Country.US)
    portYYV = new Port("Vancouver", Country.CANADA)

    shipKR = new Ship("King Roy", portYYV)
    shipKR.start

    this
  }

  def tearDown = { 
    processor.exit
    this
  }

  def arrivalSetsShipsLocation = {
    println("\n===> arrivalSetsShipsLocation")

    processor ! DepartureEvent(new Date(2009, 2, 1), portSFO, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 3), portSFO, shipKR)
    Thread.sleep(500)

    assert(portSFO == (shipKR !? CurrentPort))
    this
  }

  def departurePutsShipOutToSea = {
    println("\n===> departurePutsShipOutToSea")

    processor ! DepartureEvent(new Date(2009, 2, 4), portLA, shipKR)
    Thread.sleep(500)

    assert(Port.AT_SEA == (shipKR !? CurrentPort))
    this
  }

  def smallTrip = {
    println("\n===> smallTrip")

    processor ! ArrivalEvent(new Date(2009, 2, 5), portLA, shipKR)
    Thread.sleep(500)

    processor ! DepartureEvent(new Date(2009, 2, 6), portYYV, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 8), portYYV, shipKR)
    Thread.sleep(500)

    processor ! DepartureEvent(new Date(2009, 2, 9), portSFO, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 11), portSFO, shipKR)
    Thread.sleep(500)

    assert(portSFO == (shipKR !? CurrentPort))
    this
  }
}

(new ActorBasedEventSourcingTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .tearDown

Which gives us the following output:

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

Pretty nice.

But now, let’s start to take advantage of the event persistence. Let’s implement event replay.

Replay

Implementing replay is actually very simple now when we have an event log. First we define a Replay event.

case object Replay extends Event

Then we need the EventProcessor to respond to this new event by first reversing the order of the event log (since functional lists are concatenated in reverse order) and then for each event invoke ‘process’.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[DomainEvent]) {
    react {
       ...

      case Replay => 
        log.reverse.foreach(_.process) 
        loop(log)
    }
  }
}

Done deal.

Test run 2

Let’s try it out by adding a new test method to our suite. Here we make use of the Reset event which resets the ship to its initial state before replaying all state transitions.

def resetAndReplayEventLog = {
  println("\n===> resetAndReplayEventLog")

  shipKR ! Reset

  processor ! Replay
  Thread.sleep(500)

  assert(portSFO == (shipKR !? CurrentPort))
  this
}

(new ActorBasedEventSourcingTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .resetAndReplayEventLog // new test method
  .tearDown

This yields the following output:

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLog
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

Replay up to a specific point in time

Finally, (my last example, I promise) let’s add the possibility of replaying the event log up to a specific date to get a snapshot of the system’s state at a particular point in time.

You know the drill by now, first define a new event; ReplayUpTo, holding the date.

case class ReplayUpTo(date: Date) extends Event

Here the event processor first reverses the log, then it applies a filter to the list which filters out all events that has been created after the date specified and finally run ‘process’ on all events in the resulting filtered list.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[DomainEvent]) {
    react {
       ...

      case ReplayUpTo(date) => 
        log.reverse.filter(_.occurred.getTime <= date.getTime).foreach(_.process) 
        loop(log)
    }
  }
}

Test run 3

So we add a last test method to our suite, one that replays all events created in earlier tests up to the date ‘2009/2/4’.

def resetAndReplayEventLogUpToDate = {
  println("\n===> resetAndReplayEventLogUpToDate")

  shipKR ! Reset

  processor ! ReplayUpTo(new Date(2009, 2, 4))
  Thread.sleep(500)

  assert(Port.AT_SEA == (shipKR !? CurrentPort))
  this
} 

(new EventSourcingWithActorsTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .resetAndReplayEventLog
  .resetAndReplayEventLogUpToDate // new test method
  .tearDown

This yield the following output.

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLog
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLogUpToDate
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

That’s all there’s to it. We have only scratched the surface on what can be done with asynchronous Event Sourcing, and as in all these kind of articles, the example is almost too simplistic to fully understand the power and flexibility of the solution. But I hope that you have understood the underlying principle enough to be able to apply it to a real-world enterprise system.

Slides for my Pragmatic Real-World Scala presentation

2009-01-30T00:00:00+01:00

Slides for my Pragmatic Real-World Scala presentation

30 Jan 2009

I have uploaded the slides for my ‘Pragmatic Real-World Scala’ talk that I gave at Jfokus yesterday to slideshare.

Enjoy.

Pragmatic Real-World Scala (short version)

Added Comments to Blog

2009-01-30T00:00:00+01:00

Added Comments to Blog

30 Jan 2009

Many people have asked for it, so I have decided to add comments to my blog again.

Thank you Disqus.

Let the discussion continue.

Back To Consulting

2009-01-10T00:00:00+01:00

Back To Consulting

10 Jan 2009

The last year has been a ride.

Startup in finance business, green field development, challenging and interesting problem domain, been pushing Scala to its limits in a real-world production setting. Its been a lot of fun and a great learning experience. (I have written some about the way we have used Scala in the “Real-World Scala” series of blog posts, check the archives if you are curious.)

But now its all over. Zero cash flow in. Knocked out by the financial crisis. To bad, we had a great product coming. But not much to do.

The good news is that I am back in the consulting business. Rewrote and redesigned my company site to mark the beginnning of a new era…well, at least a “new” job.

Check it out and let me know if you need help :-)

http://scalablesolutions.se

Blogging Like a Hacker using Git and Jekyll

2009-01-07T00:00:00+01:00

Blogging Like a Hacker using Git and Jekyll

7 Jan 2009

For the last year and have been falling in love with Git. Git is truly an amazing…..tool. I was going to say Source Code Management System (SCM), but that ain’t fair, Git is so much more. Git deserves a post on its own, however in this one I’m going to talk about one of the things it can help you with; to blog like a hacker.

For the last year I have not only used Git but have hosted my whole professional life on GitHub. GitHub started as a server with Git repositories but have since then grown into a thriving community with a lot of interesting and cool features and side projects up its sleeve. One of these “features” is Jekyll. Jekyll is a minimalistic blog engine based upon Git. It allows you to write all your blog posts in either Textile, Markdown or HTML while having Git (and GitHub) take care of storage, versioning etc.

It is dead simple. Generates everything into static HTML, which I think is great. And as with all viral good open source, there are already a bunch of plug-ins such as for example converting your MT, WordPress, Typo etc blogs into Textile/Markdown for Jekyll to consume. The thing I like most is that everything is plain text, residing in your Git repository (e.g. on your file system). This means that I can write my blog post in Emacs, commit the changes using the Emacs (emacs-git), push it up to GitHub using Emacs, generate my site and FTP it up to my server from Emacs (replace Emacs with your favorite editor). Never been easier (or more fun) to blog. Hopefully this will make me do it more often.

For a sample of a Jekyll-powered blog, take a look at mine: http://jonasboner.com

Real-World Scala: Fault-tolerant Concurrent Asynchronous Components

2008-12-11T00:00:00+01:00

Real-World Scala: Fault-tolerant Concurrent Asynchronous Components

Introduction

In a previous post I wrote about Scala OTP, an initial attempt to bring the power or Erlang OTP, in particular its supervisor hierarchies and generic server to the Scala Actors library. OTP is one of the key parts in the Erlang success story and is in my opinion a requirement for Scala Actors to succeed in the real world.

Actors can simplify concurrent programming and reasoning immensely and I believe that Scala Actors is a key piece in the future Java concurrency puzzle. However, programming with actors and with explicit message passing and message dispatch loops can feel a bit unnatural and unnecessary verbose for Java developers that are used to regular OO method invocations and synchronous control flow.

For example, if we want to be able to pass a single message from one actor to the next we have to define two things.

A message with optional payload.

case class MyMessage(payload: AnyRef)

A message dispatch matching loop (partial function) in the receiving actor.

def act = {
  loop {
    react {
      case MyMessage(payload) =&gt; 
        ...  // do something with payload
      case _ => 
        ... // default case
    }
  }
}

It is also complicated to do things like stateful control flow, e.g. send message to A, wait for reply, then send message to B, wait for reply, then do C. (this can in some ways be addressed using monad continuations, but is still not simple and intuitive to use).

Don’t get me wrong. Even though it has its “flaws”, using actors (message-passing concurrency) for concurrent programming is still so much simpler than using threads and locks (shared-state concurrency).

Active Objects (Concurrent Asynchronous Components)

In this post I’ll outline a little library that we have been using that tries to unify Scala Actors, Scala OTP (supervisor hierarchies for fault tolerance) and regular OO method dispatch into an asynchronous component framework that I think can be best described as Active Objects.

Each so-called Active Object (concurrent asynchronous component) is a GenericServer that is managed by a Supervisor, either in isolation or as part of a supervisor hierarchy/tree. E.g. each component is fully fault-tolerant. For more information about how supervisor hierarchies work, read this post. Each component consists of an interface (trait) and a regular Scala class as implementation for the interface. The catch is that each component has to be instantiate through a factory. Let’s first take a look at the API and how to use this thing before we dig into the actual implementation.

Usage

Here is a simple example of a component that is using default supervisor management (which among other things mean that it is not part of a supervisor tree/hierarchy, but is still managed and will be restarted upon failure). We start with the component interface and implementation.

  trait Foo {
    def foo(msg: String): String    
    @oneway def bar(msg: String)
  }

  class FooImpl extends Foo {
    def foo(msg: String): String = { println("foo: " + msg); msg } 
    def bar(msg: String) = println("bar: " + msg)
  }

Now let’s instantiate this component. The integer 1000 specifies the time interval an (asynchronous) invocation should have before timing out.

  val foo = ActiveObject.newInstance[Foo](classOf[Foo], new FooImpl, 1000)

Now we can use this component as any regular instance of Foo. The difference is that invocations are now asynchronously dispatched in an event-based actor with its return value is wrapped in a Future, this emulates synchronous behavior but is non-blocking. The exception to this behavior is if a method is annotated with the @scala.actors.annotation.oneway annotation, then it returns immediately. All components created through the factory are fault-tolerant GenericServers managed by a Supervisor, which means that they will be restarted upon failure using the restart scheme the supervisor has defined it under.

   // use as usual
   foo.foo("foo")
   foo.bar("bar") // returns immediately since annotated with @oneway

Now, if I would like to have more control over the Supervisor configuration and/or want to compose different components into supervisor hierarchies, then we can use another factory method along with a method called start that allows us to pass in a Supervisor configuration (as defined by the Scala OTP Supervisor).

Let’s take a look at a full example:

  trait Foo {
    def foo(msg: String): String    
    @oneway def bar(msg: String)
  }

  class FooImpl extends Foo {
    val bar: Bar = new BarImpl 
    def foo(msg: String): String = { println("foo: " + msg); msg } 
    def bar(msg: String) = bar.bar(msg)
  }

  trait Bar {
    def bar(msg: String)
  }

  class BarImpl extends Bar {
    def bar(msg: String) = println("bar: " + msg)
  }

First create proxies (GenericServers) for our services.

  val fooProxy = new ActiveObjectProxy(new FooImpl, 1000)
  val barProxy = new ActiveObjectProxy(new BarImpl, 1000)

Then let’s configure the GenericServer(s) by creating a list of GenericServer configurations (defining lifecycles, restart strategies etc.). This configuration is passed into the ActiveObject.supervise method which starts up the Supervisor which starts up all GenericServer’s according to their configurations before returning the Supervisor instance (which can be used for management of the components).

val supervisor = 
  ActiveObject.supervise(
    RestartStrategy(AllForOne, 3, 100),
    Component(
      fooProxy,
      LifeCycle(Permanent, 100)) ::
    Component(
      barProxy,
      LifeCycle(Permanent, 100))
    :: Nil)

Create and use the components as in the previous example..

  val foo = ActiveObject.newInstance[Foo](classOf[Foo], fooProxy)
  val bar = ActiveObject.newInstance[Bar](classOf[Bar], barProxy)

  foo.foo("foo ") 
  bar.bar("bar ")

That pretty much sums it up. So how is this implemented?

Implementation

The first thing we need to do is to define an invocation context, holding arguments, method to be invoked as well as the target instance.

  case class Invocation(val method: Method, val args: Array[AnyRef], val target: AnyRef) {
    def invoke: AnyRef = method.invoke(target, args:_*)
    override def toString: String = "Invocation [method: " + method.getName + ", args: " + args + ", target: " + target + "]"
    override def hashCode(): Int = { ... }
    override def equals(that: Any): Boolean = { ... }
  }

The second thing we need to do is to create a dynamic proxy wrapping the asynchronous dispatch. This proxy holds an instance of an actor dressed up in a GenericServer. Now comes the little trick; we will now use the Invocation context as the message to our GenericServer actor.

As you can see in the code for the dispatcher we are defining a partial function that is defined for two different messages; Invocation and 'exit. If the Invocation message is received, then we invoke the invocation context, e.g. the method on the implementation instance and are returning the result to the caller using reply(..). If we receive an 'exit message and we terminate the GenericServer.

The call flow for this proxy is as follows. When a regular synchronous method invocation is made on the service interface or component is redirected to the invoke(..) method. In this method we simply create an invocation context for this specific method invocation and sends it as a message to our GenericServer (server). Here we have two options. If the target method is annotated with the @scala.actors.annotation.oneway annotation then we fire the message and forget by invoking server ! invocation, else we are sending the message using the server !!! invocation operator which returns a Future which we then wait on (emulating a synchronous method call).

class ActiveObjectProxy(val target: AnyRef, val timeout: Int) extends InvocationHandler {
  private val oneway = classOf[scala.actors.annotation.oneway]
 
  private[ActiveObjectProxy] object dispatcher extends GenericServer {
    override def body: PartialFunction[Any, Unit] = {
      case invocation: Invocation =>
        try {
          reply(ErrRef(invocation.invoke))
        } catch {
          case e: InvocationTargetException =&gt; reply(ErrRef({ throw e.getTargetException }))
          case e =&gt; reply(ErrRef({ throw e }))
        }
      case 'exit =&gt; exit; reply()
      case unexpected => throw new ActiveObjectException("Unexpected message to actor proxy: " + unexpected)
    }
  }
 
  private[component] val server = new GenericServerContainer(target.getClass.getName, () => dispatcher)
  server.setTimeout(timeout)
  
  def invoke(proxy: AnyRef, m: Method, args: Array[AnyRef]): AnyRef = invoke(Invocation(m, args, target))
 
  def invoke(invocation: Invocation): AnyRef = {
    if (invocation.method.isAnnotationPresent(oneway)) server ! invocation // fire and forget
    else {
      val result: ErrRef[AnyRef] = server !!! (invocation, ErrRef({ throw new ActiveObjectInvocationTimeoutException("proxy invocation timed out after " + timeout + " milliseconds") }))
      result() // wait on future for result
    }
  }
}

Finally we create a factory which will do the Supervisor configuration, wiring and startup.

object ActiveObject {
 
  def newInstance[T](intf: Class[T] forSome {type T}, target: AnyRef, timeout: Int): T = {
    val proxy = new ActiveObjectProxy(target, timeout)
    supervise(proxy)
    newInstance(intf, proxy)
  }
 
  def newInstance[T](intf: Class[T] forSome {type T}, proxy: ActiveObjectProxy): T = {
    Proxy.newProxyInstance(
      proxy.target.getClass.getClassLoader,
      Array(intf),
      proxy).asInstanceOf[T]
  }
 
  def supervise(restartStrategy: RestartStrategy, components: List[Component]): Supervisor = {
    object factory extends SupervisorFactory {
      override def getSupervisorConfig: SupervisorConfig = {
        SupervisorConfig(restartStrategy, components.map(c => Worker(c.component.server, c.lifeCycle)))
      }
    }
    val supervisor = factory.newSupervisor
    supervisor ! scala.actors.behavior.Start
    supervisor
  }
 
  private def supervise(proxy: ActiveObjectProxy): Supervisor =
    supervise(
      RestartStrategy(OneForOne, 5, 1000),
      Component(
        proxy,
        LifeCycle(Permanent, 100))
      :: Nil)
}

That’s pretty much all there is to it. The code is available as part of the Scala OTP library:

http://github.com/jboner/scala-otp/tree/master/component

Check it out by invoking: git clone git://github.com/jboner/scala-otp.git

All ideas, improvements, patches etc. are most welcome.

Real-World Scala: Managing Cross-Cutting Concerns using Mixin Composition and AOP

2008-12-09T00:00:00+01:00

Real-World Scala: Managing Cross-Cutting Concerns using Mixin Composition and AOP

In a previous post I showed you how you could use mixin composition and self type annotations to enable Dependency Injection (DI). Mixin composition is an extremely powerful tool that you can utilize in many different ways to enable modular and reusable code. In this post I’ll try to show you how you can use it to solve the problem of crosscutting concerns using AOP/interceptor-style composition.

Crosscutting concerns and AOP

OOP has given us tools to reduce software complexity by introducing concepts like inheritance, abstraction, and polymorphism. However, developers face daily problems in software design that can’t be solved easily using OOP. One of these problems is how to handle cross-cutting concerns in the application.

So what is a cross-cutting concern? A concern is a particular concept or area of interest. For example, in an ordering system the core concerns could be order processing and manufacturing, while the system concerns could be transaction handling and security management. A cross-cutting concern is a concern that affects several classes or modules, a concern that is not well localized and modularized.

Symptoms of a cross-cutting concern are:

Code tangling – when a module or code section is managing several concerns simultaneously
Code scattering – when a concern is spread over many modules and is not well localized and modularized

These symptoms affect software in various ways; for example, they make it harder to maintain and reuse software as well as harder to write and understand.

Aspect-Oriented Programming (AOP) tries to solve these problems by introducing the concept of separation of concerns, in which concerns can be implemented in a modular and well-localized way. AOP solves this by adding an extra dimension to the design space, and introduces constructs that allow us to define the cross-cutting concerns, to lift them out into a new dimension and package them in a modular way.

We are currently using two different types of interceptors (aspects if you like):

Mixin composition stacks — a limited but sometimes very useful approach
Generic interceptors/aspects using a pointcut pattern language

Mixin composition stacks

Mixin composition stacks is a core language feature of Scala and is similar to Rickard Oberg’s idea on using the so-called Abstract Schema pattern for type-safe AOP in plain Java. (This is a very contrived example that probably shows that don’t know a zip about dogs, but please bare with me.)

First let’s define a couple of interfaces; Dog and DogMood modeled as a mixins (in this case without an implementation so similar to Java’s interface):

trait Dog {
  def greet(me: Human)
}

trait DogMood extends Dog {
  def greet(me: Human) {
    println(me.sayHello)
  }
}

Now let’s define two different mixin “interceptors” that implement these interfaces. The first one defining an angry dog and the other one a hungry dog:

trait AngryDog extends DogMood {
  abstract override def greet(me: Human) {
    println("Dog: Barks @ " + me)
    super.greet(me)
  }
}

trait HungryDog extends DogMood {
  abstract override def greet(me: Human) {
    super.greet(me)
    println("Dog: Bites " + me)
  }
}

As we can see in this example they both override the Mood.greet method. If we look more closely we can see that they follow the same pattern:

Enter method (greet)
Do something
Invoke the same method on super (super.greet)
Do something else

The trick here is in the semantics of the call to super. Here Scala will invoke the next mixin in a stack of mixins, e.g. the same method in the “next” mixin that have been mixed in. Exactly what f.e. AspectJ does in its proceed(..) method and what Spring does in its interceptors.

Now let’s fire up the Scala REPL and create a component based on the Dog interface. Scala’s mixin composition can take place when we instantiate an instance, e.g. it allows us to mix in functionality into specific instances that object creation time for specific object instances.

scala> val dog = new Dog with AngryDog with HungryDog 
stuff2: Dog with AngryDog with HungryDog = $anon$1@1082d45

scala> dog.greet(new Human("Me"))
Dog: Barks @ Me
Me: Hello doggiedoggie
Dog: Bites Me

As you can see the call to Dog.greet is intercepted by the different moods that are added to the dog at instantiation time.

Interceptors like this are as you can see not generically reusable since they are tied to a specific interface, however if well designed can be a pretty powerful technique. It has the advantage that everything is statically compiled and type-checked by the Scala compiler

Generic pointcut-based aspects

The main usage of generic aspects is for implementing infrastructure concerns such as logging, transaction demarcation, security, clustering, persistence etc.

In order to create a framework for implementing generic aspects, the first thing we need to do is to define an invocation context, holding arguments, method to be invoked as well as the target instance.

case class Invocation(val method: Method, val args: Array[AnyRef], val target: AnyRef) {
  def invoke: AnyRef = method.invoke(target, args:_*)
  override def toString: String = "Invocation [method: " + method.getName + ", args: " + args + ", target: " + target + "]"
  override def hashCode(): Int = { ... }
  override def equals(that: Any): Boolean = { ... }
}

The second thing that we need to do is to create a base Interceptor trait. This interface defines two different pointcut matching methods. The first one matches a precompiled AspectJ pointcut expression using the PointcutParser in AspectJ. This allows defining interceptors matches AspectJ compatible (method) pointcut expressions. The second matcher matches methods or classes that is annotated with a specific annotation.

trait Interceptor {
  protected val parser = PointcutParser.getPointcutParserSupportingAllPrimitivesAndUsingContextClassloaderForResolution

  protected def matches(pointcut: PointcutExpression, invocation: Invocation): Boolean = {
    pointcut.matchesMethodExecution(invocation.method).alwaysMatches ||
    invocation.target.getClass.getDeclaredMethods.exists(pointcut.matchesMethodExecution(_).alwaysMatches) ||
    false
  }

  protected def matches(annotationClass: Class[T] forSome {type T <: Annotation}, invocation: Invocation): Boolean = {
    invocation.method.isAnnotationPresent(annotationClass) ||
    invocation.target.getClass.isAnnotationPresent(annotationClass) ||
    false
  }

  def invoke(invocation: Invocation): AnyRef
}

The last thing we need to do is to create a factory method allows us to wire in our interceptors, declarative, in a seamless fashion. This factory is using the plain old Java Dynamic Proxy API to create a proxy for our base components.

object ManagedComponentFactory {
  def createComponent[T](intf: Class[T] forSome {type T}, proxy: ManagedComponentProxy): T =
    Proxy.newProxyInstance(
      proxy.target.getClass.getClassLoader,
      Array(intf),
      proxy).asInstanceOf[T]
}

class ManagedComponentProxy(val target: AnyRef) extends InvocationHandler {
  def invoke(proxy: AnyRef, m: Method, args: Array[AnyRef]): AnyRef = invoke(Invocation(m, args, target))
  def invoke(invocation: Invocation): AnyRef = invocation.invoke
}

Just using this factory pass is won’t do any wiring for us, which is actually good since if we would use the dynamic proxy the old-fashioned way and we would have it to invoke each interceptor explicitly using reflection. But we can do better than that. Instead we will let the Scala compiler statically compiled in an interceptor stack with all our interceptors. This is best explained with an example.

In this example we will define a couple of simple services called Foo and Bar along with their implementations. We will then implement two different infrastructure in interceptors; logging and transaction demarcation.

Let’s first define the service.

  import javax.ejb.{TransactionAttribute, TransactionAttributeType}

  trait Foo {
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    def foo(msg: String)
    def bar(msg: String)
  }

  class FooImpl extends Foo {
    val bar: Bar = new BarImpl
    def foo(msg: String) = println("msg: " + msg)
    def bar(msg: String) = bar.bar(msg)
  }

  trait Bar {
    def bar(msg: String)
  }

  class BarImpl extends Bar {
    def bar(msg: String) = println("msg: " + msg)
  }

Now let’s define a logging interceptor. Both of these interceptors are just mockups, since the actual implementation is not really of interest. The logging interceptor is defined using a standard AspectJ pointcut while the transaction interceptor is wired to a specific annotation.

  trait LoggingInterceptor extends Interceptor {
    val loggingPointcut = parser.parsePointcutExpression("execution(* *.bar(..))")

    abstract override def invoke(invocation: Invocation): AnyRef = 
      if (matches(loggingPointcut , invocation)) {
        println("=====> Enter: " + invocation.method.getName + " @ " + invocation.target.getClass.getName)
        val result = super.invoke(invocation)
        println("=====> Exit: " + invocation.method.getName + " @ " + invocation.target.getClass.getName)
        result
      } else super.invoke(invocation)
  }

  trait TransactionInterceptor extends Interceptor {
    val matchingJtaAnnotation = classOf[javax.ejb.TransactionAttribute]

    abstract override def invoke(invocation: Invocation): AnyRef = 
      if (matches(matchingJtaAnnotation, invocation)) {
        println("=====> TX begin")
        try {
          val result = super.doStuff
          println("=====> TX commit")
          result     
        } catch {
          case e: Exception => 
            println("=====> TX rollback ")
        } 
      } else super.invoke(invocation)
  }

Now let’s do the wiring. Here we are using dynamic proxy-based factory that we implemented because you can see, the actual wiring on the interceptor stack is done using Scala mixing composition and therefore has all its benefits, like compiler type checking and enforcement, the speed of statically compiled code, refactoring safety etc.

  var foo = ManagedComponentFactory.createComponent[Foo](
    classOf[Foo],
    new ManagedComponentProxy(new FooImpl)
      with LoggingInterceptor
      with TransactionInterceptor)

  foo.foo("foo")
  foo.bar("bar")
 }

This will produce the following output:

=====> TX begin
msg: foo
=====> TX commit
=====> Enter: bar @ FooImpl
msg: bar
=====> Exit: bar @ FooImpl

So this wraps it up. I hope that you have learned a little bit about how powerful mixin composition in Scala is and how it can be used to write modular and reusable components with little effort.

This is working fine for us, but there is definitely room for improvement. For example, runtime matcher in the interceptor is fast enough for the annotation matching (only a boolean check) but the AspectJ pointcut matcher is a bit slower since it has to do some more work. This might turn out be a problem or not, most infrastructure services (like persistence and security) performs quite a lot to work and in these cases the overhead over the interceptor of matching will not affect the overall performance much, but in other cases (such as logging or auditing) it might. We are so far only use the annotation matching, so it has not turned out to be a problem so far. However, if it turns out to be a performance bottleneck then we will most likely switch to using my old AspectWerkz AWProxy to get rid of all the Java reflection code and runtime matching.

For those that are interested, here is the actual JTA transaction demarcation interceptor that we are using in production (implementing all the EJB transaction semantics).

trait EjbTransactionInterceptor extends Interceptor with TransactionProtocol {
  val matchingJtaAnnotation = classOf[javax.ejb.TransactionAttribute]

  abstract override def invoke(invocation: Invocation): AnyRef = if (matches(matchingJtaAnnotation, invocation)) {
    val txType = getTransactionAttributeTypeFor(invocation.target.getClass, invocation.method)
    if (txType == TransactionAttributeType.REQUIRED)           withTxRequired { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.REQUIRES_NEW)  withTxRequiresNew { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.MANDATORY)     withTxMandatory { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.NEVER)         withTxNever { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.SUPPORTS)      withTxSupports { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.NOT_SUPPORTED) withTxNotSupported { super.invoke(invocation) }
    else super.invoke(invocation)
  } else super.invoke(invocation)
}

Reward Failure

2008-10-14T00:00:00+02:00

Reward Failure

Alex Miller has written a very important post on the importance of failure, putting, what has been one of my guiding principles in leadership and working environment building, in words.

It can’t be emphasized enough that for a company to be a leader and not a follower one of the most important things is to foster an environment that encourages and rewards failure – as a potential outcome of taking risks, trying crazy ideas out and out-of-the-box-thinking. It is only in a working environment where the fear of failing has been eliminated that the employees are set free to create amazing things.

This was one of the things that I loved most while working for Terracotta, an amazing place to be working at, and one of the reason why it has managed to hire and keep so many brilliant developers and visionaries.

Real-World Scala: Dependency Injection (DI)

2008-10-06T00:00:00+02:00

Real-World Scala: Dependency Injection (DI)

Update: Corrected typo in the Cake Pattern version of the last example.
Update: Added a version of the last example using the Cake Pattern for easier
comparison (see end of post).

In this second post in the Real-World Scala series I am going to discuss how to implement/achieve Depenency Injection (DI) in Scala. Scala is a very rich and deep language that gives you several ways of doing DI solely based on language constructs, but nothing prevents you from using existing Java DI frameworks, if that is preferred.

At Triental we tried out three different strategies before settling for the one we are using now. The plan for this article is as follows; first explain in detail how we are doing DI now, and then briefly cover the other alternative strategies we have tried out.

Using the Cake Pattern

The current strategy we are using is based on the so-called Cake Pattern. This pattern is first explained in Martin Oderskys’ paper Scalable Component Abstractions (which is an excellent paper that is highly recommended) as the way he and his team structured the Scala compiler. But rather than trying to explain the pattern and how it can be used to implement DI in plain English let’s take a look at some (naive) sample code (loosely based on our production code).

Note:
I will try to explain things in steps which I refactor towards the final version (this is only to help with the understanding), so please wait with yelling: “This sucks!”, until you have read and understood the final version (after which you are of course allowed come with any criticism/praise/suggestions/ideas you feel is necessary). Also, the sample code will, as in all these kind of examples, look like an insanely complicated way of doing almost nothing, but bare with me and try to envision real services in a large production system and how it applies there.

First, let’s create a UserRepository (DAO) implementation.

// a dummy service that is not persisting anything
// solely prints out info
class UserRepository {
  def authenticate(user: User): User = { 
    println("authenticating user: " + user)
    user
   }
  def create(user: User) = println("creating user: " + user)
  def delete(user: User) = println("deleting user: " + user)
}

Here we could have split up the implementation in a trait interface and its implementation, but in order to keep things simple I didn’t see the need.

Now let’s create a user service (also a dummy one, merely redirecting to our repository).

class UserService {
  def authenticate(username: String, password: String): User = 
    userRepository.authenticate(username, password)  

  def create(username: String, password: String) = 
    userRepository.create(new User(username, password))

  def delete(user: User) = All is statically typed.  
    userRepository.delete(user)
}

Here you can see that we are referencing an instance of the UserRepository. This is the dependency that we would like to have injected for us.

Ok. Now the interesting stuff starts. Let’s first wrap the UserRepository in an enclosing trait and instantiate the user repository there.

trait UserRepositoryComponent {
  val userRepository = new UserRepository
  class UserRepository {
    def authenticate(user: User): User = { 
      println("authenticating user: " + user)
      user
    }
    def create(user: User) = println("creating user: " + user)
    def delete(user: User) = println("deleting user: " + user)
  }
}

This simply creates a component namespace for our repository. Why? Stay with me and I’ll show you how to make use of this namespace in a second.

Now let’s look at the UserService, the user of the repository. In order to declare that we would like to have the userRepository instance injected in the UserService we will first do what we did with the repository above; wrap the it in an enclosing (namespace) trait and use a so-called self-type annotation to declare our need for the UserRepository service. Sounds more complicated than it is. Let’s look at the code.

// using self-type annotation declaring the dependencies this 
// component requires, in our case the UserRepositoryComponent
trait UserServiceComponent { this: UserRepositoryComponent =>
  val userService = new UserService  
  class UserService {
    def authenticate(username: String, password: String): User = 
      userRepository.authenticate(username, password)  
    def create(username: String, password: String) = 
      userRepository.create(new User(username, password))
    def delete(user: User) = userRepository.delete(user)
  }
}

The self-type annotation we are talking about is this code snippet:

this: UserRepositoryComponent =>

If you need to declare more than one dependency then you can compose the annotations like this:

this: Foo with Bar with Baz =>

Ok. Now we have declared the UserRepository dependency. What is left is the actual wiring.

In order to do that the only thing we need to do is to merge/join the different namespaces into one single application (or module) namespace. This is done by creating a “module” object composed of all our components. When we do that all wiring is happening automatically.

object ComponentRegistry extends
  UserServiceComponent with
  UserRepositoryComponent

One of the beauties here is that all wiring is statically typed. For example, if we have a dependency declaration missing, if it is misspelled or something else is screwed up then we get a compilation error. This also makes it very fast.

Another beauty is that everything is immutable (all dependencies are declared as val).

In order to use the application we only need to get the “top-level” component from the registry, and all other dependencies are wired for us (similar to how Guice/Spring works).

val userService = ComponentRegistry.userService
...
val user = userService.authenticate(..)

So far so good?

Well, no. This sucks.

We have strong coupling between the service implementation and its creation, the wiring configuration is scattered all over our code base; utterly inflexible.

Let’s fix it.

Instead of instantiating the services in their enclosing component trait, let’s change it to an abstract member field.

trait UserRepositoryComponent {
  val userRepository: UserRepository

  class UserRepository {
    ...
  }
}

trait UserServiceComponent { 
  this: UserRepositoryComponent => 

  val userService: UserService  

  class UserService {
    ... 
  }
}

Now, we can move the instantiation (and configuration) of the services to the ComponentRegistry module.

object ComponentRegistry extends 
  UserServiceComponent with 
  UserRepositoryComponent 
{
  val userRepository = new UserRepository
  val userService = new UserService
}

By doing this switch we have now abstracted away the actual component instantiation as well as the wiring into a single “configuration” object.

The neat thing is that we can here switch between different implementations of the services (if we had defined an interface trait and multiple implementations). But even more interestingly, we can create multiple “worlds” or “environments” by simply composing the traits in different combinations.

To show you what I mean, we’ll now create a “testing environment” to be used during unit testing.

Now, instead of instantiating the actual services we instead create mocks to each one of them. We also change the “world” to a trait (why, I will show you in a second).

trait TestingEnvironment extends
  UserServiceComponent with
  UserRepositoryComponent with 
  org.specs.mock.JMocker
{
  val userRepository = mock(classOf[UserRepository])
  val userService = mock(classOf[UserService])
}

Here we are not merely creating mocks but the mocks we create are wired in as the declared dependencies wherever defined.

Ok, now comes the fun part. Let’s create a unit test in which we are mixing in the TestEnvironment mixin, which is holding all our mocks.

class UserServiceSuite extends TestNGSuite with TestEnvironment {

  @Test { val groups=Array("unit") }
  def authenticateUser = {

    // create a fresh and clean (non-mock) UserService 
    // (who's userRepository is still a mock)
    val userService = new UserService

    // record the mock invocation
    expect {
      val user = new User("test", "test")
      one(userRepository).authenticate(user) willReturn user
    }
    
    ... // test the authentication method
  }
  
  ...
}

This pretty much sums it up and is just one example on how you can compose your components in the way you want.

Other alternatives

Let’s now take a look at some other ways of doing DI in Scala. This post is already pretty long and therefore I will only walk through the techniques very briefly, but it will hopefully be enough for you to understand how it is done. I have based all these remaining examples on the same little dummy program to make it easier to digest and to compare (taken from some discussion found on the Scala User mailing list). In all these examples you can just copy the code and run it in the Scala interpreter, in case you want to play with it.

Using structural typing

This technique using structural typing was posted by Jamie Webb on the Scala User mailing list some time ago. I like this approach; elegant, immutable, type-safe.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}

// =======================
// service declaring two dependencies that it wants injected,
// is using structural typing to declare its dependencies
class Warmer(env: {
  val potSensor: SensorDevice
  val heater: OnOffDevice
}) {
  def trigger = {
    if (env.potSensor.isCoffeePresent) env.heater.on
    else env.heater.off
  }
}

class Client(env : { val warmer: Warmer }) {
  env.warmer.trigger
}

// =======================
// instantiate the services in a configuration module 
object Config {
  lazy val potSensor = new PotSensor
  lazy val heater = new Heater
  lazy val warmer = new Warmer(this) // this is where injection happens
}

new Client(Config)

Using implicit declarations

This approach is simple and straight-forward. But I don’t really like that the actual wiring (importing the implicit declarations) is scattered and tangled with the application code.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}

// =======================
// service declaring two dependencies that it wants injected
class Warmer(
  implicit val sensor: SensorDevice, 
  implicit val onOff: OnOffDevice) {

  def trigger = {
    if (sensor.isCoffeePresent) onOff.on
    else onOff.off
  }
}

// =======================
// instantiate the services in a module 
object Services {
  implicit val potSensor = new PotSensor
  implicit val heater = new Heater
}

// =======================
// import the services into the current scope and the wiring 
// is done automatically using the implicits
import Services._

val warmer = new Warmer
warmer.trigger

Using Google Guice

Scala works nicely with separate DI frameworks and early on we were using Google Guice. You can use Guice in many different ways, but here we will discuss a slick technique based on a ServiceInjector mixin that my Jan Kriesten showed me.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}
trait IWarmer {
  def trigger
}
trait Client

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}
class @Inject Warmer(
  val potSensor: SensorDevice, 
  val heater: OnOffDevice) 
  extends IWarmer {

  def trigger = {
    if (potSensor.isCoffeePresent) heater.on
    else heater.off
  }
}

// =======================
// client
class @Inject Client(val warmer: Warmer) extends Client {
  warmer.trigger
}

// =======================
// Guice's configuration class that is defining the 
// interface-implementation bindings 
class DependencyModule extends Module {
  def configure(binder: Binder) = {
    binder.bind(classOf[OnOffDevice]).to(classOf[Heater])
    binder.bind(classOf[SensorDevice]).to(classOf[PotSensor])
    binder.bind(classOf[IWarmer]).to(classOf[Warmer])
    binder.bind(classOf[Client]).to(classOf[MyClient])
  }
}

// =======================
// Usage: val bean = new Bean with ServiceInjector
trait ServiceInjector {
  ServiceInjector.inject(this)
}

// helper companion object 
object ServiceInjector {
  private val injector = Guice.createInjector(
    Array[Module](new DependencyModule))
  def inject(obj: AnyRef) = injector.injectMembers(obj)
}

// =======================
// mix-in the ServiceInjector trait to perform injection
// upon instantiation
val client = new MyClient with ServiceInjector

println(client)

That sums up what I had planned to go through in this article. I hope that you have gained some insight in how one can do DI in Scala, either using language abstractions or a separate DI framework. What works best for you is up to your use-case, requirements and taste.

Update:

Below I have added a Cake Pattern version of the last example for easier comparison between the different DI strategies. Just a note, if you compare the different strategies using this naive example then the Cake Pattern might look a bit overly complicated with its nested (namespace) traits, but it really starts to shine when you have a less then trivial example with many components with more or less complex dependencies to manage.

// =======================
// service interfaces
trait OnOffDeviceComponent {
  val onOff: OnOffDevice
  trait OnOffDevice {
    def on: Unit
    def off: Unit
  }
}
trait SensorDeviceComponent {
  val sensor: SensorDevice
  trait SensorDevice {
    def isCoffeePresent: Boolean
  }
}

// =======================
// service implementations
trait OnOffDeviceComponentImpl extends OnOffDeviceComponent {
  class Heater extends OnOffDevice {
    def on = println("heater.on")
    def off = println("heater.off")
  }
}
trait SensorDeviceComponentImpl extends SensorDeviceComponent {
  class PotSensor extends SensorDevice {
    def isCoffeePresent = true
  }
}
// =======================
// service declaring two dependencies that it wants injected
trait WarmerComponentImpl {
  this: SensorDeviceComponent with OnOffDeviceComponent =>
  class Warmer {
    def trigger = {
      if (sensor.isCoffeePresent) onOff.on
      else onOff.off
    }
  }
}

// =======================
// instantiate the services in a module
object ComponentRegistry extends
  OnOffDeviceComponentImpl with
  SensorDeviceComponentImpl with
  WarmerComponentImpl {

  val onOff = new Heater
  val sensor = new PotSensor
  val warmer = new Warmer
}

// =======================
val warmer = ComponentRegistry.warmer
warmer.trigger

Real-World Scala: Introduction

2008-10-01T00:00:00+02:00

Real-World Scala: Introduction

The last nine months I have been running my own business together with some friends (Triental AB). We are building a product suite for private banking and wealth management with a focus on portfolio management, analysis and simulation.

One of the great things of being your own is that you get to choose whatever technology you like and think is best suitable for the job. The last years I have been studying and playing with Functional Programming (FP) in general and Scala in particular (among with Erlang, Clojure and Haskell). FP has been used successfully in the financial domain before (for example Jane Street Capital (OCaml) and Business Objects (CAL)), and the work we do is heavily based on mathematics which maps excellent to the FP paradigm.

Apart from the FP properties (such as immutability, high-order functions, closures etc.) Scala also have some other interesting properties such as:

Mixin composition (enables creation of components build up of reusable fragments, even runtime composition)
Actors library (message-passing concurrency, an easy way of parallelizing long-running computations and simulations out on multi-core or SMP machines)
Flexible syntax with decent type inference (high productivity, great for DSLs etc.)
Statically typed (fast, in most cases as fast as Java)
Pattern matching
Seamless interoperability with Java
and much much more

So I decided to try use FP and Scala for real.

By choosing to base the development on FP and a new and fairly unproven (at least in the industry) language like Scala, we were exposing ourselves to two main risks:

Technology: will the technology deliver, can we fix or work around the problems that will emerge down the road etc.?
Education: will the process and time needed to be invested in learning a new language and paradigm slow us down too much?

And will the benefit of using it in terms of:

higher productivity,
cleaner, more stable and more reusable code, and
more fun

outweigh the potential risks and upfront time (and money) investment?

To be honest, the trip has been a bit bumpy sometimes, but now after nine months of development I can say that Scala pulled it off. Both of these risks were manageable. We are very happy with the strategic decision to use Scala.

Technology-wise, one of the biggest problems of using Scala in a JEE application stack is that there are (currently) no frameworks, patterns or “best-practices” that will help you address fundamental issues like:

Dependency Injection (DI)
Code tangling and scattering e.g. AOP
Transaction demarcation and context propagation
Component life-cycle

Basically, we didn’t have a “container” that could handle this for us so we had to write it ourselves. The good thing is that most Java frameworks works very nicely with Scala. For example, we have had using no problems using JPA, Wicket etc. and deploy it in a standard JEE appserver.

Regarding the second risk; education, it turned out to not be much of an issue. Our developers who had never written a line in Scala and had very little experience with FP in general were fully up to speed in a couple of months. The first weeks there were some complaints but now they are loving it. Scala gives a smooth learning curve to FP since it, being a unique blend of the OO and FP paradigms, allows one to start with a very Java-esque imperative style of programming and gradually move towards a functional style. Now we have rewritten most of the imperative chunks of code that were written during the early education stages.

This is the first post in a series of articles in which I will try to explain how we are bridging the “Scala <—> Real-World” gap. I have to stress that these are by no means the only way to do things and perhaps not the best way of doing things, but simply the way we have solved our problems and what work for us. Hopefully it will also work for you.

For those that are interested here is a list of the Scala frameworks that we are currently using:

Scala (for the domain model, persistence layer, service layer, facade layer and container code)
Configgy (logging and configuration)
Scala OTP (actor management)
Lift (misc util)
scalax (misc util)
ScalaTest (testing)
ScalaCheck (testing)

The rest is a fairly standard Java stack:

Wicket
Hibernate (JPA)
Atomikos (JTA)
Terracotta
Wicket-Push (Cometd)
Dojo
AspectJ
XStream
TestNG
DBUnit
EasyMock
MySQL
Jetty
Maven
Hudson

The topics I am planning on covering are:

Dependency Injection
AOP
Transaction demarcation (JTA) and context propagation
Asynchronous event-driven components
ORM (JPA)

Stay tuned for the next article.

The Book Is Out

2008-06-30T00:00:00+02:00

The Book Is Out

The Definite Guide to Terracotta by me and my colleagues; Ari, Geert, Alex, Orion and Taylor, is now available in the stores.
It is a pragmatic and practical book, with tons of real-world examples and stories, so if you want to learn how to use Terracotta for real then go and order a copy.

Erlang-style Supervisor Module for Scala Actors

2008-06-16T00:00:00+02:00

Erlang-style Supervisor Module for Scala Actors

In this post I will explain how you can build fault-tolerant systems using Scala Actors by arranging them in Supervisor hierarchies using a library for Scala Supervisors that I just released.

But first, let’s recap what Actors are and what makes them useful.

An actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simpler concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and making it easier to avoid problems like deadlocks, live locks, thread starvation etc. This makes it possible to write code that is deterministic and side-effect-free, something that makes easier to write, test, understand and reason about. Each actor has a mailbox in which it receives incoming messages and can use pattern matching on the messages to decide if a message is interesting and which action to take. The most well known and successful implementation of actors can be found in the Erlang language (and the OTP platform) where it has been used to implement extremely fault tolerant (99.9999999% reliability – 9 nines) and massively concurrent systems (with hundreds of thousand simultaneous actors).

So what are Supervisor hierarchies? Let’s go to the source; http://www.erlang.org/doc/design_principles/sup_princ.html#5.

A supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary.

It has two different restart strategies; All-For-One and One-For-One. Best explained using some pictures (referenced from erlang.org):

OneForOne

AllForOne

Naturally, the library I have written for Scala is by no means as complete and hardened as Erlang’s, but it seems to do a decent job in providing the core functionality.

The implementation consists of two main abstractions; Supervisor and GenericServer.

The Supervisor manages hierarchies of Scala actors and provides fault-tolerance in terms of different restart semantics. The configuration and semantics is almost a 1-1 port of the Erlang Supervisor implementation, explained in the erlang.org doc referenced above. Read this document in order to understand how to configure the Supervisor properly.

The GenericServer (which subclasses the Actor class) is a trait that forms the base for a server to be managed by a Supervisor.

The GenericServer is wrapped by a GenericServerContainer instance providing a necessary indirection needed to be able to fully manage the life-cycle of the GenericServer in an easy way.

So, let’s try it out by writing a small example in which we create a couple of servers, configure them, use them in various ways, kill one of them, see it recover, hotswap its implementation etc.

(Sidenote: I have written about hotswapping actors before, however this library has taken this approach a but further and provides a more flexible and powerful way of achieving this. Thanks DPP.)

This walk-through will only cover some of the API, for more details look at the code or the tests.

1. Create our server messages

import scala.actors._
import scala.actors.Actor._

import com.jonasboner.supervisor._
import com.jonasboner.supervisor.Helpers._

sealed abstract class SampleMessage
case object Ping extends SampleMessage
case object Pong extends SampleMessage
case object OneWay extends SampleMessage
case object Die extends SampleMessage

2. Create a GenericServer
We do that by extending the GenericServer trait and override the body method.

class SampleServer extends GenericServer {

  // This method implements the core server logic and naturally has to be overridden
  override def body: PartialFunction[Any, Unit] = {
    case Ping => 
      println("Received Ping"); reply(Pong)

    case OneWay => 
      println("Received OneWay")

    case Die => 
      println("Received Die..dying...") 
      throw new RuntimeException("Received Die message")
  }

}

GenericServer also has some callback life-cycle methods, such as init(..) and shutdown(..).

3. Wrap our SampleServer in a GenericServerContainer
Here we also give it a name to be able to refer to it later. We are creating two instances of the same server impl in order to try out multiple server restart in case of failure.

object sampleServer1 extends GenericServerContainer("sample1", () => new SampleServer)
object sampleServer2 extends GenericServerContainer("sample2", () => new SampleServer)

4. Create a Supervisor configuration
Here we create a SupervisorFactory that is configuring our servers. The configuration mimics the Erlang configuration and defines a general restart strategy for our Supervisor as well as a list of workers (servers) which for each we define a specific life-cycle.

object factory extends SupervisorFactory {
  override protected def getSupervisorConfig: SupervisorConfig = {
    SupervisorConfig(
      RestartStrategy(AllForOne, 3, 10000),
       Worker(
        sampleServer1,
        LifeCycle(Permanent, 1000)) ::
       Worker(
        sampleServer2,
        LifeCycle(Permanent, 1000)) ::
      Nil)
  }
}

5. Create a new Supervisor

val supervisor = factory.newSupervisor

Output:



12:25:30.031 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Configuring supervisor:com.jonasboner.supervisor.Supervisor@860d49

12:25:30.046 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1b9240e] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.062 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1808199] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.062 [main] DEBUG Main$factory$2$ – Supervisor successfully configured

6. Start the Supervisor
This also starts the servers.

supervisor ! Start

Output:



12:25:30.078 [Thread-8] INFO  com.jonasboner.supervisor.Supervisor – Starting server: Main$sampleServer2$2$1479feb
12:25:30.078 [Thread-8] INFO  com.jonasboner.supervisor.Supervisor - Starting server: Main$sampleServer1$2$97a560

7. Try to communicate with the servers.
Here we try to send a couple one way asynchronous messages to our servers.



sampleServer1 ! OneWay

Try to get a reference to our sampleServer2 (by name) from the Supervisor before sending a message.

supervisor.getServer("sample2") match {
  case Some(server2) => server2 ! OneWay
  case None => println("server [sample2] could not be found")
}

Output:



Received OneWay

Received OneWay

8. Send a message using a future
Try to send an asynchronous message – receive a future – and wait 100 ms (time-out) for the reply.

val future = sampleServer1 !! Ping
val reply1 = future.receiveWithin(100) match {
  case Some(reply) => 
    println("Received reply: " + reply)
  case None => 
    println("Did not get a reply witin 100 ms")
}

Output:



Received Ping

Received reply: Pong

9. Kill one of the servers
Try to send a message (Die) telling the server to kill itself (by throwing an exception).

sampleServer1 ! Die

Output:



Received Die..dying…

12:25:30.093 [Thread-8] ERROR c.j.supervisor.AllForOneStrategy – Server [Main$SampleServer$1@1b9240e] has failed due to [java.lang.RuntimeException: Received Die message] – scheduling restart – scheme: ALL_FOR_ONE.

12:25:30.093 [Thread-8] DEBUG Main$sampleServer2$2$ – Waiting 1000 milliseconds for the server to shut down before killing it.

12:25:30.093 [Thread-8] DEBUG Main$sampleServer2$2$ – Server [sample2] has been shut down cleanly.

12:25:30.093 [Thread-8] DEBUG c.j.supervisor.AllForOneStrategy – Restarting server [sample2] configured as PERMANENT.

12:25:30.093 [Thread-8] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@166aa18] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.093 [Thread-8] DEBUG Main$sampleServer1$2$ – Waiting 1000 milliseconds for the server to shut down before killing it.

12:25:30.093 [main] DEBUG com.jonasboner.supervisor.Helpers$ – Future timed out while waiting for actor: Main$SampleServer$1@1b9240e

Expected exception: java.lang.RuntimeException: Time-out

12:25:31.093 [Thread-8] DEBUG c.j.supervisor.AllForOneStrategy – Restarting server [sample1] configured as PERMANENT.

12:25:31.093 [Thread-8] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1968e23] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

10. Send an asyncronous message and wait on a future.

If this call times out, the error handler we define will be invoked – in this case throw an exception. It is likely that this call will time out since the server is in the middle of recovering from failure and we are on purpose defining a very short time-out to trigger this behavior.

val reply2 = try {
  sampleServer1 !!! (Ping, throw new RuntimeException("Time-out"), 10) 
} catch { case e => println("Expected exception: " + e.toString); Pong }

The output of this call (due to the async nature of actors) is interleaved with the logging for the restart of the servers. As you can see the log below can be found in the middle of the restart output.



12:25:30.093 [main] DEBUG com.jonasboner.supervisor.Helpers$ – Future timed out while waiting for actor: Main$SampleServer$1@1b9240e

Expected exception: java.lang.RuntimeException: Time-out

Server should be up again. Try the same call again

val reply3 = try {
  sampleServer1 !!! (Ping, throw new RuntimeException("Time-out"), 1000) 
} catch { case e => println("Expected exception: " + e.toString); Pong }

Output:



Received Ping

Also check that server number 2 is up and healthy.

sampleServer2 ! Ping

Output:



Received Ping

11. Try to hotswap the server implementation
Here we are passing in a completely new implementation of the server logic (doesn’t look that different tough, but it can be any piece of scala pattern matching code) to the server’s hotswap method.

sampleServer1.hotswap(Some({
  case Ping => 
    println("Hotswapped Ping")
}))

12. Try the hotswapped server out

sampleServer1 ! Ping

Output:



Hotswapped Ping

13. Hotswap again

sampleServer1.hotswap(Some({
  case Pong => 
    println("Hotswapped again, now doing Pong")
    reply(Ping)
}))

14. Send an asyncronous message that will wait on a future (using a different syntax/method).
Method returns an Option[T] which can be of two different types; Some(result) or None. If we receive Some(result) then we return the result, but if None is received then we invoke the error handler that we define in the getOrElse method. In this case print out an info message (but you could throw an exception or do whatever you like…) and return a default value (Ping).

val reply4 = (sampleServer1 !!! Pong).getOrElse({
  println("Time out when sending Pong")
  Ping
})

Output:



Hotswapped again, now doing Pong

Same invocation with pattern matching syntax.

val reply5 = sampleServer1 !!! Pong match {
  case Some(result) => result
  case None => println("Time out when sending Pong"); Ping  
}

Output:



Hotswapped again, now doing Pong

15. Hotswap back to original implementation.
This is done by passing in None to the hotswap method.

sampleServer1.hotswap(None)

16. Test the final hotswap

sampleServer1 !  Ping

Output:



Received Ping

17. Shut down the supervisor and its server(s)

supervisor ! Stop

Output:



12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor – Stopping server: Main$sampleServer2$2$1479feb
12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor - Stopping server: Main$sampleServer1$2$97a560

12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor – Stopping supervisor: com.jonasboner.supervisor.Supervisor@860d49

You can find this code in the sample.scala file in the root directory of the distribution. Run it by invoking:



scala -cp target/supervisor-0.3.jar:[dependency jars: slf4j and logback] sample.scala

Check out
The SCM system used is Git.

1. Download and install Git
2. Invoke git clone git@github.com:jboner/scala-supervisor.git.

Build it
The build system used is Maven 2.

1. Download and install Maven 2.
2. Step into the root dir scala-supervisor.
3. Invoke mvn install

This will build the project, run all tests, create a jar and upload it to your local Maven repository ready for use.

Runtime dependencies
Automatically downloaded my Maven.

1. Scala 2.7.1-final
2. SLF4J 1.5.2
3. LogBack Classic 0.9.9

That’s all to it.

Have fun.

AOP-style Mixin Composition Stacks in Scala

2008-02-06T00:00:00+01:00

AOP-style Mixin Composition Stacks in Scala

Scala is one those great languages that is scalable. With scalable I mean that it is the language that grows with the user, that it makes simple things easy and hard things possible. A language that is easy to get started and to become productive in, but at the same time a deep language with very powerful constructs and abstractions.

In this blog post I will try to highlight the power of Scala’s mixins and how you can use mixin composition to get AOP/interceptor-like style of programming.

First let’s define our service interface, modeled as a mixin (in this case without an implementation so similar to Java’s interface):

trait Stuff {
  def doStuff
}

Now let’s define two different mixin “interceptors” that implement the service interface. The first one manages logging and the other one transaction demarcation (but for simplicity I am just using a dummy mock for TX stuff for now):

trait LoggableStuff extends Stuff {
  abstract override def doStuff {
    println("logging enter")
    super.doStuff
    println("logging exit")
  }
}

trait TransactionalStuff extends Stuff {
  abstract override def doStuff {
    println("start TX")
    try {
      super.doStuff
      println("commit TX")      
    } catch {
      case e: Exception => 
        println("rollback TX")   
    } 
  }
}

As we can see in this example they both override the Stuff.doStuff method. If we look more closely we can see that they follow the same pattern:

Enter method (doStuff)
Do something (log, start tx etc.)
Invoke the same method on super (super.doStuff)
Do something (log, commit tx etc.)

But before we try this out, let’s create a concrete implementation of our Stuff service, called RealStuff:

class RealStuff {
  def doStuff = println("doing real stuff")
}

Now we have everything we need, so let’s fire up the Scala REPL and create a component based on the RealStuff class and a mixin stack with support for logging and transactionality. Scala’s mixin composition can take place when we instantiate an instance, e.g. it allows us to mix in functionality into specific instances that object creation time for specific object instances.

First let’s create a plain RealStuff instance and run it:



scala> import stacks._

import stacks._
scala> val stuff = new RealStuff 

stuff: stacks.RealStuff = $anon$1@6732d42
scala> stuff.doStuff

doing real stuff

Not too exciting, but let’s do it again and this time mix in the LoggableStuff mixin:

scala> val stuff2 = new RealStuff with LoggableStuff 
stuff2: stacks.RealStuff with stacks.LoggableStuff = $anon$1@1082d45

scala> stuff2.doStuff
logging enter
doing real stuff
logging exit

As you can see the call to RealStuff.doStuff is intercepted and logging is added before we are invoking this method as well as after. Let’s now add the TransactionalStuff mixin:

scala> val stuff3 = new RealStuff with LoggableStuff with TransactionalStuff
stuff3: stacks.RealStuff with stacks.LoggableStuff with stacks.TransactionalStuff = $anon$1@4512d65

scala> stuff3.doStuff
start TX
logging enter
doing real stuff
logging exit
commit TX

As you can see, the semantics for this mixin stack is the exact same as you would get with stacking AspectJ aspects or Spring interceptors. Another interesting aspect is that the whole composition is statically compiled with all its benefits of compile time error detection, performance, potential tool support etc.

This approach is similar to Rickard Oberg’s idea on using the so-called Abstract Schema pattern for type-safe AOP in plain Java.

It is both simple and intuitive to change the order of the mixin “interceptors”, simply change the order in which they are applied to the target instance:

scala> val stuff4 = new RealStuff with TransactionalStuff with LoggableStuff
stuff4: stacks.RealStuff with stacks.TransactionalStuff with stacks.LoggableStuff = $anon$1@a20232

scala> stuff4.doStuff
logging enter
start TX
doing real stuff
commit TX
logging exit

Finally, just for fun, let’s a create a mixin that can retry failing operations. This particular one will catch any exception that the service might throw and retry it three times before giving up:

trait RetryStuff extends Stuff {
  abstract override def doStuff {
    var times = 0
    var retry = true
    while (retry) {
      try {
        super.doStuff      
        retry = false
      } catch {
        case e: Exception => 
          if (times < 3) { // retry 3 times
            times += 1
            println("operation failed - retrying: " + times)
          } else {
            retry = false
            throw e 
          }
      }
    }
  }
}

To test this behavior (as well as the rollback feature in the TransactionalStuff) we can change the RealStuff.getStuff method to throw an exception:



class RealStuff {

  def doStuff {

    println(“doing real stuff”)

    throw new RuntimeException(“expected”)

  }

}

Now we can try to add this mixin to the beginning of our our stack and run the service:

scala> val stuff5 = new RealStuff with RetryStuff with TransactionalStuff  with LoggableStuff
stuff5: stacks.RealStuff with stacks.RetryStuff with stacks.LoggableStuff with stacks.TransactionalStuff = $anon$1@a927d45

scala> stuff5.doStuff
logging enter
start TX
doing real stuff
operation failed - retrying: 1
doing real stuff
operation failed - retrying: 2
doing real stuff
operation failed - retrying: 3
rollback TX
logging exit

Pretty neat, right?

That’s all for now. In the next post I will cover a bunch of ways to use Scala’s language primitives to do Dependency Injection (DI).

Clustering Scala Actors with Terracotta

2008-01-25T00:00:00+01:00

Clustering Scala Actors with Terracotta

Introduction

A month ago I wrote an introductory post about Scala Actors: HotSwap Code using Scala and Actors. For you who don’t know what it is I don’t want to start by reading the previous post let’s briefly recap what Actors are and what you can use them for.

An Actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simple concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and is avoiding most of the latter one’s complexity and problems. This makes it possible to write code that is deterministic and side-effect-free, something that makes it easier to write, test, understand and reason about. Each Actor has a mailbox in which it receives incoming messages and normally uses pattern matching on the messages to decide if a message is interesting if action is needed.

Scala’s Actors are based on Doug Lea’s Fork/Join library and have for example been used very effectively in the excellent lift web framework to among other things to enable Comet style (push/streaming ajax) development. Actors allows us to, in a simple and uniformed way, parallelize applications using multiple threads, something that helps us take advantage of all the new dual/quad/… core or SMP machines that we are starting to get now days. But this also poses challenges; how can we make applications build on this “new” programming model highly available and how can we scale them out, if necessary. Would it not be cool if we could not only parallelize our application onto multiple threads but also onto multiple machines?

Note: Erlang, the most successful implementation of Actors to date, solves the challenges in building fault-tolerant and highly available systems in an elegant way using supervisor hierarchies. Nothing prevents an implement of this strategy in Scala Actors, all the primitives (like link, trap_exit etc.) already exists.

I have spent some time last weeks looking into if would make sense to utilize Terracotta to cluster the Scala Actors library to give a platform on which we can both scale Actors out in a distributed fashion and ensure full fault tolerance and high-availability. The result of this exercise have been successful and I’m happy to announce that they work very nice together. I will now spend the remainder of this post on walking you through a simple example in how to cluster a Scala Actor using Terracotta.

Check out the code from SVN

But before we do anything, let my point you to the SVN repository where you can fetch the Terracotta Integration Module (TIM) that I have implemented for Scala Actors. You can check it out anonymously by invoking:

svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-scala-actors-2.6.1/

When that is done, step into tim-scala-actors-2.6.1/trunk and invoke mvn install (the last command requires that you have Maven installed). it’ll take a while for Maven to download all its dependencies but after a while you will have a shiny new TIM for Scala Actors installed in your local Maven repository (usually in ~/.m2). The sample that we will discuss in the next sections is available in the src/samples/scala directory with the sample configuration in the src/samples/resources directory.

Write an Actor

Now, let’s write a little Cart actor. This actor response to two different messages AddItem(item) and Tick. The former one adds an item to the Cart while the latter one triggers the Cart to print out its content (I’ll let you know why it’s called Tick in a second):

// Messages
case object Tick
case class AddItem(item: String)
  
class Cart extends Actor {
  private[this] var items: List[String] = Nil 

  def act() {
    loop {
      react {
        case AddItem(item) =>
          items = item :: items
        case Tick =>
          println("Items: " + items)
      }
    }
  }
  
  def ping = ActorPing.scheduleAtFixedRate(this, Tick, 0L, 5000L)
}

As you see the state is held by a Scala var, which holds onto a List (immutable). In react we wait for the next incoming message and if it is of type AddItem then we grab the item and append it to the list with all our items, but if the message is of type Tick we simply print the list of items out. Simple enough. But what is this method ping doing? It uses an object called ActorPing to schedule that a Tick should be sent to the Cart every 5 seconds (ActorPing is shamelessly stolen from Dave Pollak’s lift).

Configuration

In order to cluster the Cart actor we have to write two things. First a hack, a simple configuration file in which declare which actors we want to cluster. This is something that later should be put into the regular tc-config.xml file, but for now we have to live with it. So let’s create a file with one single line, stating the fully qualified name of the Cart actor;

 samples.Cart

We can either name this file clustered-scala-actors.conf and put it in root directory of the application or name it whatever we want and feed it to Terracotta using the -Dclustered.scala.actors.config=[path to the file] JVM property. Second, we have to write the regular Terracotta configuration file (tc-config.xml). Here we essentially have to define three things; the TIM for Scala Actors, locks to guard our mutable state and finally which classes should be included for bytecode instrumentation.

Starting with the TIM for Scala Actors. Here we define the version on the module as well as the URL to our Maven repository (in a short while we will put this jar in the Terracotta Maven repository and then you would not have to point out a local one).

<modules>
 <repository>file:///Users/jonas/.m2/repository</repository>
 <module name="clustered-scala-actors-2.6.1" version="2.6.0.SNAPSHOT"/>
</modules>

Now we have to define the locks, which in Terracotta, also marks the transaction boundaries. The Cart has one mutable field (the var named items) that we need to ensure is guarded correctly and has transactional semantics. For each var Scala generates a setter and a getter. The getter is named the same as the field while the getter has the name suffixed with _$eq. That gives us the following lock definition:

<locks>
  <named-lock>
    <lock-name>cart_items_write</lock-name>
    <lock-level>write</lock-level>
    <method-expression>* samples.Cart.items_$eq(..)</method-expression>
  </named-lock>
  <named-lock>
    <lock-name>cart_items_read</lock-name>
    <lock-level>read</lock-level>
    <method-expression>* samples.Cart.items()</method-expression>
  </named-lock>
</locks>

We have to define a pair like this for each mutable user defined field in a clustered actor (not the standard one’s that are common for all Scala Actors, those are automatically defined).

It important to understand the TIM automatically clusters the Actor’s mailbox, which means that no messages will ever be lost – providing full fault-tolerance.

Finally we have to define the classes that we need to include for instrumentation. This naturally includes our application classes, e.g. the classes that are using our Cart actor in one way or the other. Those are picked out by the pattern like: 'samples.*'. We also have to include all the Scala runtime and library classes that we are referencing from the message is that we send. In our case that means the classes that are used to implement the List abstraction in Scala. Here is the full listing:

<instrumented-classes>
 <include>
   <class-expression>samples.*</class-expression>
 </include>
 <include>
   <class-expression>scala.List</class-expression>
 </include>
 <include>
   <class-expression>scala.$colon$colon</class-expression>
 </include>
 <include>
   <class-expression>scala.Nil$</class-expression>
 </include>
</instrumented-classes>

I could have included these (and many more) classes in the TIM, but since Terracotta adds a tiny bit of overhead to each class that it instruments I took the decision that it would be better to let the user explicitly define the classes that needs to be instrumented and leave the other ones alone. Since you can pretty much put any valid Scala data or abstraction in an actor message, it is very likely that you will have to declare some includes, else Terracotta will throw an exception (which is expected) with a message listing the XML snippet that you have to put in the tc-config.xml file. So don’t panic if things blow up.

Enable Terracotta

Last but not least, we need to enable Terracotta in the Scala runtime (if you are planning to run the application in a Terracotta enabled application server, then you can skip this section – however I think it might still be useful to be able to try the application out in the Scala REPL). The simplest way of doing that is to do some minor changes to the scala command. First, let’s step down into the scala/bin directory and make a copy of the scala command called tc-scala, then scroll down all the way to the bottom. As you can see it is just a wrapper around the regular java command, which makes things pretty easy for us. We start by defining some environmental variables (here showing my local settings):

TC_SCALA_ACTORS_CONFIG_FILE=/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/clustered-scala-actors.conf
TC_CONFIG_FILE=/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/tc-config.xml
TC_INSTALL_DIR=/Users/jonas/src/java/tc/code/base/build/dist/terracotta-trunk-rev6814
TC_BOOT_JAR="$TC_INSTALL_DIR"/lib/dso-boot/dso-boot-hotspot_osx_150_13.jar
TC_TIM_SCALA_ACTORS_JAR=/Users/jonas/.m2/repository/org/terracotta/modules/clustered-scala-actors-2.6.1/2.6.0-SNAPSHOT/clustered-scala-actors-2.6.1-2.6.0-SNAPSHOT.jar

When these variables have been defined we can replace the existing invocation of java with the following:

${JAVACMD:=java} ${JAVA_OPTS:=-Xmx256M -Xms256M} \
 -Xbootclasspath/p:"$TC_BOOT_JAR" \
 -Dtc.install-root="$TC_INSTALL_DIR" \
 -Dtc.config="$TC_CONFIG_FILE" \
 -Dclustered.scala.actors.config="$TC_SCALA_ACTORS_CONFIG_FILE" \
 -Dscala.home="$SCALA_HOME" \
 -Denv.classpath="$CLASSPATH" \
 -Denv.emacs="$EMACS" \
 -cp "$BOOT_CLASSPATH":"$EXTENSION_CLASSPATH":"$TC_TIM_SCALA_ACTORS_JAR" \
 scala.tools.nsc.MainGenericRunner  "$@"

Let’s run it

Enough hacking. Now let’s try it out. I think that the best way of learning new things in Scala is to use its REPL, so let’s start that up, this time with Terracotta enabled. But before we do that we have to start up the Terracotta server by stepping into the bin directory in the Terracotta installation and invoke:

$ ./start-tc-server.sh

Note: you need to grab Terracotta from SVN trunk to get the bits that work with the Scala TIM. See instructions on how to check out the sources and how to build it.

Now, we can start up the Terracotta enabled Scala REPL:

$ tc-scala
2008-01-25 07:42:11,643 INFO - Terracotta trunk-rev6814, as of 20080124-140101 (Revision 6814 by jonas@homer from trunk)
2008-01-25 07:42:12,136 INFO - Configuration loaded from the file at '/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/tc-config.xml'.
2008-01-25 07:42:12,325 INFO - Log file: '/Users/jonas/terracotta/client-logs/scala/actors/20080125074212303/terracotta-client.log'.
Parsing scala actors config file: /Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/clustered-scala-actors.conf
Configuring clustering for Scala Actor: samples.Cart
Welcome to Scala version 2.6.0-final.
Type in expressions to have them evaluated.
Type :help for more information.

scala>

Here we can see that it has found and connected to the Terracotta server, found our clustered-scala-actors.conf config file and configured clustering for one Scala Actor; samples.Cart.

Let’s have some fun and start up another REPL in another terminal window. In each of these we do the following; import our classes, create a new Cart (Actor) and start up the Actor.

scala> import samples._              
import samples._

scala> val cart = new Cart
cart: samples.Cart = samples.Cart@81af82

scala> cart.start
res0: scala.actors.Actor = samples.Cart@81af82

scala>

Now we have a distributed Actor just waiting to be fed with some messages. We don’t want to make it disappointed so let’s now add a bunch of bananas and apples to the Cart, and then feed it with a Tick message to make it print out the result:

scala> cart ! AddItem("bananas")

scala> cart ! AddItem("apples")

scala> cart ! Tick

scala> Items: List(apples, bananas)

scala>

Ok, so far no news. But comes the moment of truth, let’s take the other REPL and fire of a Tick:

scala> cart ! Tick

scala> Items: List(apples, bananas)

scala>

Yippee, it works. Now we can invoke the ping method to schedule a Tick (to print out status) every 5 seconds.

scala> cart.ping
res2: java.util.concurrent.ScheduledFuture = java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3a4388

scala> Items: List(apples, bananas)

scala> Items: List(apples, bananas)

scala> cart ! AddItem("football")

scala> Items: List(football, apples, bananas)

...

How to define scope of the clustered Actor?

The Scala Actors TIM currently supports three different scopes; instance, class and custom. The scope is defined by appending a colon ‘:’ and the type of scope after the FQN of the Actor in the clustered-scala-actors.conf. If no scope is defined then the Actor is assumed to have scope instance. For example:

com.biz.Foo:custom
com.biz.Bar:class
com.biz.Baz:instance  
com.biz.Bam

The default scope named instance means that the Scala TIM is transparently intercepting the instantiation (f.e. new Cart) of all the Actors that you declare in the clustered-scala-actors.conf file. Each clustered Actor instance will have a unique identity across the cluster and each time this specific instance is created (f.e. when a new node joins the cluster) then the clustered instance with this specific identity will be handed out. The TIM distinguishes between actors of the same type but instantiated in different code paths. To take an example, let’s create one object ActorFactory with one single method create:

object ActorFactory {
  def create: Actor = new MyActor
}

If we now have two classes Foo and Bar as follows:

class Foo {
  val actor = ActorFactory.create
}

class Bar {
  val actor = ActorFactory.create
}

Then Foo and Bar will have two distinct clustered Actors each with a unique but cluster-wide identity.

The class scope lets all Actors of a the same type share Actor instance, so each time an Actor of a specific type is created the same clustered one will be handed out.

Finally we have the custom scope. Which, as it sounds, allows custom user defined scoping.

How to define custom scoped Actors?

If you want more control over scope and life-cycle of a specific Actor then you can define it to have custom scope in the clustered-scala-actors.conf file and create a factory in which you bind each Actor to whatever scope you wish. But now you have to create some data structure that is holding on to your Actors in the factory and explicitly define it to be a root in the tc-config.xml file. The factory might look something like this:

// Cart factory, allows mapping an instance to any ID
object Cart {
  
  // This instance is the custom Terracotta root
  private[this] val instances: Map[Any, Cart] = new HashMap

  def newInstance(id: Any): Cart = {
    instances.get(id) match {
      case Some(cart) => cart
      case None => 
        val cart = new Cart
        instances += (id -> cart)
        cart
    }
  }
}

This means that we have to add some more configuration elements to our Terracotta configuration. First we need to add the root samples.Cart$.instances (Cart$ is the name of Scala’s compiled Cart companion object, all companion objects compiles to a class with the name of the original class suffixed with $):

<roots>
  <root>
    <field-name>samples.Cart$.instances</field-name>
  </root>
</roots>

Then we have to add locking for the Cart.newInstance(..) method and finally a whole bunch of new include statements for all the Scala types that are referenced by the scala.collection.mutable.HashMap that we used as root:

...  
<named-lock>
  <lock-name>Cart_newInstance</lock-name>
  <lock-level>write</lock-level>
  <method-expression>* samples.Cart$.newInstance(..)</method-expression>
</named-lock>

...
          
<include>
  <class-expression>scala.collection.mutable.HashMap</class-expression>
</include>
<include>
  <class-expression>scala.runtime.BoxedAnyArray</class-expression>
</include>
<include>
  <class-expression>scala.runtime.BoxedArray</class-expression>
</include>
<include>
  <class-expression>scala.collection.mutable.DefaultEntry</class-expression>
</include>
  
...

That’s pretty much all there’s to it. Check out the code, play with it and come back with feedback, bug reports, patches etc.

Enjoy.

HotSwap Code using Scala and Actors

2007-12-19T00:00:00+01:00

HotSwap Code using Scala and Actors

Update: In this article I am showing an even more powerful way of doing hotswap in Scala:
http://jonasboner.com/2008/06/16/erlang-style-supervisor-module-for-scala-actors.html.
Se the bottom of this article for an example of how this is used to enable hotswap of arbitrary pieces of pattern matching code.

In this post I will show you how you can do code hotswap in the same fashion as in Erlang using Scala and its Actors package.

An actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simpler concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and is avoiding all of the latter one’s problems with deadlocks, live locks, thread starvation etc. This makes it possible to write code that is deterministic and side-effect-free, something that makes easier to write, test, understand and reason about. Each actor has a mailbox in which it receives incoming messages and can use pattern matching on the messages to decide if a message is interesting and which action to take. The most well known and successful implementation of actors can be found in the Erlang language (and the OTP platform) where it has been used to implement extremely fault tolerant (99.9999999% reliability – 9 nines) and massively concurrent systems (with hundreds of thousand simultaneous actors).

Let’s start by writing a little server. We implement this in the form of a trait, which is Scala’s mixin construct. Traits allows you to build up your components using so-called mixin composition which is something that can give you a very high grade of reuse and flexibility. This trait only defines a single method named status which prints out info about the enclosing instance. Completely useless and not much for a server, but it will give you the idea. Then we subclass this mixin and define the ServerOne concrete server class (with the status method mixed in).

// servers
trait Server {
  def status = println("current server: " + this)
}
class ServerOne extends Server

Let’s instantiate the ServerOne class and see what the status method it will print out. Here we are doing it interactively through Scala’s REPL (read-eval-print-loop).

$ scala -cp .

scala> val server = new ServerOne
server: ServerOne = ServerOne@7be75d

scala> server status
current server: ServerOne@7be75d

Now, before we write the actor we have to define the messages it responds to. Here Scala is using something called case classes which are similar to normal classes but with some enhancements. First you can match on them, e.g. use pattern matching similar to the one found in Erlang. They also have some syntactic sugar, f.e. you can create them without using new, the compiler generates getters and setters for the constructor arguments, equality is not based on object id but on meaning/content (something that makes them ideal to use for value objects, but that is another story). We define two different messages; Status and HotSwap.

// triggers the status method
case object Status

// triggers hotswap - carries the new server to be hotswapped to
case class HotSwap(s: Server)

Ok, now it is time for the actual actor. Actor is a base class in the Scala library and we can choose to either extend it explicitly or to create an anonymous actor through the actor {...} construct. When we subclass the actor we have to implement the method called act which is the callback method that is invoked when the actor is started up.

Scala comes with two different implementations; one that is based on Java threads in that each actor is getting its own thread, while the other one is based on events and very lightweight allowing hundreds of thousands of actors to run simultaneously. Here we will use the event-based version (which is done by using the react method instead of the receive method for receiving messages).

The trick to do hotswap by using actors is to loop recursively and pass on the state in each recursive call. This is a very common idiom in functional programming. The beauty of it is that we do not update any mutual state but our execution is side effect free which makes it easier to test and reason about. In this case our state is the actual server. We start the loop by instantiating ServerOne. The pattern matching is happening in react statement in which we have three different cases (pattern matchers).

The first one matches our Status, when we receive this message we simply invoke the status method on our server and then taking another round in the loop passing along the server.

The second one matches our HotSwap message. It is here things are starting to get interesting. Now we can take the new replacement server (here called newServer), which is passed to us as an argument to the HotSwap message, and pass it in to the call to the loop method. Voila, we have updated our server at runtime. Now all subsequent messages will act on our new server instance.

This will work since the react method will in fact never return but infinitely recur. Infinite recursion would have been a problem in f.e. Java since each recursion would consume a new stack frame until we run out of memory. But recursion is one of the most powerful and commonly used idioms in functional programming and the Scala compiler optimizes tail-recursive algorithms and turns them into regular loops.

At the end we have also added a match-all pattern that does nothing, this is defined by the case _ => ... clause. Let’s take a look at the code.

class ServerActor extends Actor {
  def act = {
    println("starting server actor...")
    loop(new ServerOne)
  }
  
  def loop(server: Server) {
    react {
      case Status => 
        server.status
        loop(server)

      case HotSwap(newServer) => 
        println("hot swapping code...")
        loop(newServer)

      case _ => loop(server)
    }
  }
}

Finally we will follow one of Scala’s idioms and create a companion object for our ServerActor class. In this object, which is a singleton but should be seen upon as a module for functions and immutable state, we define an immutable handle to an instantiated and started actor.

Worth to note is that the val holding our actor is initialized when the enclosing object is first used, and since we are starting up the actor in the initialization block of the val, the actor will not be started until it is used for the first time.

// actor companion object
object ServerActor {
  val actor = {
    val a = new ServerActor
    a.start; a
  }
}

Let’s try to run it in the Scala REPL. The Scala function ! (pronounced bang) means “send a message”. So act ! msg means send message msg to actor act.

$ scala -cp .  

scala> import hotswap._
import hotswap._

scala> val actor = ServerActor.actor
starting actor...
actor: hotswap.ServerActor = hotswap.ServerActor@528ed7

scala> actor ! Status
current server: hotswap.ServerOne@226445

scala> class ServerTwo extends Server {
     | override def status = println("hotswapped server: " + this)
     | }
defined class ServerTwo

scala> actor ! HotSwap(new ServerTwo)
hot swapping code...

scala> actor ! Status
hotswapped server: line5$object$$iw$$iw$$iw$ServerTwo@b556

Pretty cool, right?

This would be even more cool if Scala came with an SSH server that could provide this REPL remotely (like we have in Erlang OTP). Then we could connect to our application from the outside and change its behavior, fixing bugs, upgrade the server etc. Another solution would be to make use of the remote actors in the Scala distribution, but that is something for another post.

Update:

This is a slightly simplified version of the GenericServer code (as discussed here), allowing hotswap of arbitrary pieces of pattern matching code:

// the actor's main loop
def act = loop { react { genericBase orElse actorBase } }

// should we go with the hotswapped impl or the regular server impl (body)
private def actorBase: PartialFunction[Any, Unit] = hotswap getOrElse body

// the hotswapped impl
private var hotswap: Option[PartialFunction[Any, Unit]] = None

// generic functionality
private val genericBase: PartialFunction[Any, Unit] = {
  case HotSwap(code) => hotswap = code
}

// the regular server implementation
def body: PartialFunction[Any, Unit] = {
  ...
}

This code can be used like this:

server ! HotSwap(Some({
  case Ping => 
    println("Ping")
}))

The Terracotta Book

2007-12-18T00:00:00+01:00

The Terracotta Book

The last month I have been very busy writing on The Definitive Guide to Terracotta.

It is a collaborative effort from the Terracotta team each one writing on chapters in their area of expertise. It is a very practical and will teach you how to use Terracotta with the X framework/appserver or for a Y use-case, yet thorough and deep in concepts and theory.

It will be available sometime next year and if you’re interested in getting updates on the book can subscribe to: bookupdate AT terracottatech DOT com.

Oredev 2007: BDD, LINQ, Scalability trends etc.

2007-11-17T00:00:00+01:00

Oredev 2007: BDD, LINQ, Scalability trends etc.

I had the pleasure of attending Oredev last month. This was a great conference. I have attended this conference three years in a row and it’s getting better and better every year.

This year they had a great speaker lineup and I was able to catch some very interesting talks. Among the most memorable ones were Dan North‘s keynote about why “Best Practices” in software development are neither “Best” no “Practices”. I also attended Dan’s talk on BDD (Behavior-Driven
Development). Great talk. I find BDD very interesting, it feels like the natural extension of, or complement to TDD (Test-Drived Development) in that it focuses on getting complete concept coverage in the tests instead of code coverage (as in TDD).

Other great talks were Andy Hunt‘s (Pragmatic Programmers) keynote and Erik Meijer’s talk on LINQ. The latter one was fun to watch, Erik (undeliberately it felt like) turned it more or less into a praise of Haskell; how they have stolen all the good stuff in LINQ from Haskell and that the world would be a better place if everyone just used Haskell.

My talk on Terracotta was able to attract quite a lot of attendees. One of the most interesting things was when I asked them, at the end of the talk, how many could see immediate need for something like Terracotta in their daily work roughly 80% raise their hands. I find this quite amazing and is actually something that have been consistent during last half year. I remember when I started asking this question, around 2 years ago, roughly 5-10 % raised their hands. This is quite a drastic change. Since I know that we were facing the same problems with scalability and HA a couple of years as we do now, I guess this is a sign of that the awareness of clustering, persistent and durable RAM and similar services has increased; that people have started to consider writing stateful applications with rich domain models – which implies another solution to HA and scalability than Oracle RAC and similar.

However, the best thing was that the conference had invited one of the best coffee shops in Malmo to serve all speakers unlimited amount of caffeine in the form of espresso, cafe latte, machiatto or whatever was asked for. I paid them 4-5 visits every day.

Interview with Joe Armstrong on Erlang and more...

2007-10-30T00:00:00+01:00

Interview with Joe Armstrong on Erlang and more…

I had the pleasure of attending Joe Armstrong’s fantastic presentation at JAOO some weeks ago. It was by far the best talk at the whole conference, both in terms of content and presentation. Joe showed deep knowledge in both hardware and software, good teaching skills all wrapped up in a dry twisted sense of British humor – Joe was incredibly funny, I sometimes felt like had attended a stand-up comedian show.

Anyway, for all of you that missed Joe’s talk, here is a great interview with him discussing Erlang’s (and a functional programmer’s) view of the world, the problem with OO, shared state concurrency and much more. Not as funny as the talk, but very interesting.

Clojure: a Lisp-dialect for the JVM - with focus on Functional and Concurrent Programming

2007-10-18T00:00:00+02:00

Clojure: a Lisp-dialect for the JVM – with focus on Functional and Concurrent Programming

Yesterday, Rich Hickey announced the birth of Clojure – a lisp dialect for the JVM.

After just a brief look, Clojure is perhaps the most interesting language in the (now fairly large) family of ‘dynamic languages for the JVM’. It brings the power of Lisp to the JVM but have made some design decisions that in some ways makes it more interesting than ANSI Common Lisp. Here are some of the things that I find particularly interesting:

Allows pure functional programming with immutable state (with immutable data-structures etc.) for side-effect-free code (possible in CL but hard to enforce).
- Immutable state can be freely shared across threads.
- Software Transactional Memory (STM) that allows atomic and isolated updates to mutable state (through “Refs”) with rollback and retry upon collision.
- Safe usage of mutable state through thread isolation (using “Vars”).
Full Lisp-style macro support and eval.
Compiles to JVM bytecode but still fully dynamic (sounds promising but I don’t know its actual performance).
Excellent integration with Java APIs, with type inference for static compilation of Java API calls.

Here are some tasters (from the forum).

Java integration:



(new java.util.Date)

=> Wed Oct 17 20:01:38 CEST 2007
(. (new java.util.Date) (getTime))

=> 1192644138751
(.. System out (println “This is cool!”))

This is cool!

Macros:

  

(defmacro time [form]

  `(let [t0# (. System (currentTimeMillis))

         res# ~form

         t1# (. System (currentTimeMillis))]

    (.. System out (println (strcat "Execution took "

                                    (/ (- t1# t0#) 1000.0) " s")))

    res#))
Usage:

(defn factorial [n]

   (if (< n 2)

       1

	n (factorial (- n 1)))))

(time (factorial 1000))

=> Execution took 0.012 s

     40…

It is still in beta but if you want to start playing around with it yourself, dive into the docs.

Dreaming on:
Stuff that I would like to see (in order to make it the ultimate playground) are among other things: message-passing concurrency (I don’t fully believe in STM…yet) and declarative pattern matching (from Erlang), implicit currying and laziness (as in Haskell), transparent distribution (as in Mozart/Oz and Erlang) and optional static typing. Some of these can be found in Qi, I just would love to see them on the JVM.