/ Java

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)

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.

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

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 very 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

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/designprinciples/supprinc.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: ALLFORONE.
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

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 you can see this example they both override the Stuff.doStuff method. If we look more closely we can see that it’s a pattern is:

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

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.

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

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/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).

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:

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:

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 $):

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:

...

  Cart_newInstance
  write
  * samples.Cart$.newInstance(..)


...






...

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

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, race conditions, 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 tens of thousands of actors to run simultaneously. Here we will use the lightweight 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.

Sidenote: the val holding our actor is initialized lazily when it is first accessed, 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.

// 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 a ! msg means send message msg to actor a.

$ scala -cp .  

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.

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, Terracotta 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…

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

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).
• Great support for concurrent programming:
  • 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.

Terracotta Podcast Part 2

The second half of an interview that Xebia did with me some months ago have been published.

In this half which we discuss Terracotta in more detail, covering Network-Attached Memory and JVM-level clustering in depth (some stuff that we cover is slightly outdated, but most of it still holds).

You can find it here.

If you missed the first part you can read more it here (which gives more of an overview).

Terracotta Podcast Part 1

Xebia did an interview with me some months ago in which we discuss Terracotta, scale-out and high-availability for Java, JVM-level clustering, network-attached memory, distributed computing, concurrent programming, JEE best practices etc.

The interview is split up in two parts, the first one being more of an overview while the second one discusses things in more detail.

You can find the first part here.

Second part will be published in 2 weeks.

Article: Distributed Web Continuations with RIFE and Terracotta

My and Geert Bevin’s article about how to cluster RIFE’s Web Continuations with Terracotta has just been published on Artima.

Here is the abstract:

In this article, we discuss how the RIFE Web framework helps you become productive and efficient in building conversational Web applications. Productivity with RIFE is in large part due to RIFE’s unique approach to Web development—its use of continuations for conversational logic, and complete integration of meta-programming to minimize boilerplate code.

We also introduce you to Terracotta and it’s JVM-level clustering technology, and show you how Terracotta and RIFE can work together to create an application stack that allows you to scale out and ensure high-availability for your applications, but without sacrificing simplicity and productivity. This means working with POJOs, and minimal boilerplate and infrastructure code.

It tries to not only explain but to show you in a pragmatic way how RIFE’s continuations and Terracotta is a perfect match with their common goal of power with simplicity. But don’t take my word for it, go on and read it yourself.