Actor concurrency for the JVM: a case study

{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma

Javaday IV – Roma – 30 gennaio 2010

Actor concurrency for the JVM: a case study

Sergio Bossa, Valerio SchiavoniJug Roma

Javaday IV - Roma - 30 gennaio 2010



Plan

Actor model

Actorom

Case study: decentralized Twitter-clone



Sergio Bossa Software architect and engineer

Gioco Digitale (online gambling and casinos) Open Source enthusiast

Terracotta Messaging (http://forge.terracotta.org) Terrastore (http://code.google.com/p/terrastore) Actorom (http://code.google.com/p/actorom)

(Micro-)Blogger http://twitter.com/sbtourist http://sbtourist.blogspot.com



Valerio Schiavoni 2007-2009, software engineer at INRIA, France 2010, begin PhD at Universitè de Neuchâtel, Switzerland Open Source

Fractal (http://fractal.ow2.org) FraSCAti (http://frascati.ow2.org)

(Micro-)Blogger http://twitter.com/vschiavoni http://jroller.com/vschiavoni

http://frascati.ow2.org

http://frascati.ow2.org



Actors' origin

Actor processing model. Originated in 1973 on a scientific paper by Carl Hewitt. Erlang owns the most well-known implementation.

At least in industry. Since 1986.

Scala recently brought it to the mainstream among mere mortals.

Why?



Why do we need actors?

Gordon E. MooreGene Amdahl

No, they're not actors



Why do we need actors?

Moore's Law. The number of transistors that can be inexpensively

placed on an integrated circuit is increasing exponentially. Not true anymore!

Amdahl's Law. Performance decreases as number of processors

increases once there is even a small percentage of non-parallelizable code.

This is our new reality!



Can you feel the pain?

We live in the multi-core/multi-processor era. But we're not prepared for it ...

Most of our software is non-parallelizable. Most of our software is written for single-processor. Most of our software has shared state.



The problem with shared state

Shared state model. The way we're used to.

We have a few variables. We have one or more threads. We have our threads accessing our variables. We have to acquire/release locks.

The right locks. In the right order. For the right resources.



The problem with shared state

Locks: use with care. They don't compose. They create contention. They create liveness problems.

Deadlock. Starvation. Livelock.

They're hard to get right!



The actors alternative

Actor concurrency model. Shared nothing. Message passing. Asynchronous. Simpler.

− Yes, I said: simpler.



Anatomy of an actor

Actors are independent processing units encapsulating their own state. They have an address. They have a mailbox. They have an encapsulated state.

− Fancy way to say they have a unique identifier, a kind of buffer and a few private variables.



A day in the life of an actor

Actors are independent processing units reacting to messages. They receive messages. They (asynchronously) change their own

encapsulated state. They send messages to other actors.

− Fancy way to say the can only receive and send messages.



Actors for the Java language

Introducing Actorom. Pure Java. Lightweight and embeddable. Intuitive, minimal APIs. Support for local in-JVM actors. Support for remote client/server actors. Open Source!

http://code.google.com/p/actorom/



Actorom concepts Base:

Topology: a container for actors. Handler: the actor behaviour. Message: the exchanged message object.

Advanced: Code swapping: change the actor behaviour at runtime. Links: chain actors lifecycle. Fail/restart policies: set-up how to react when actors fail. Client/Server remoting: use actors remotely running.



Playing ping-pong with actors

First actor implementation.




Second actor implementation.




Messages implementation.




Let the play begin.



Our case study



Think: what is Twitter?



Twitter: centralized model

Ciip Ciop



Does it scale?



It did not in the past..

2007



..and again..

2008



..and again..

2009



and..

2010

bit.ly/twitter-availability



why is this happening?



Flaws in a centralized design

A centralized model has certain advantages anda number of drawbacks

Scale up to hundreds of millions of active users is a challenge



Introducing a different model

At this point, you should have a vague idea of why we need a different model

Twittor

A “quasi” decentralized Twitter clone



Now think again: what “really” is?

* Social network ?* Micro-blogging service ?* Real-time bulletin board ?* Asynchronous chat?

* At its core, it’s a centralized and difficult to scale publish-subscribe system



Twittor

Exploit the power of the message-passing paradigm implemented by Actorom

Remove the central-server that handles publications

Let the twitters interconnect to each other “directly”



From Twitter...



..to Twittor

?



High-level description

One actor represents a user of the system, a twittorA twittor has a unique nickA twittor can send messages to other twittors A twittor follows and it’s followed by other twittors

Which messages flow in the system ?



Messages, part 1

1) Register(“ugo”,addr)

2) (optional) AckRegister

3) Follow(“ugo”)

4) FollowResponse({“ugo”:addr})



Why “quasi” ?

This is a “special” actor that actsas a naming service/registry: it’s a

potential weakness in the example.Different designs can implement

distributed group membership avoiding it. For the sake of

simplicity of the example, we kept it



RegisterMessage



RegisterActorHandler



FollowMessage



FollowHandler



FollowResponseMessage



FollowResponseHandler



Messages, part 2

Push(“tweet!”)

To publish, 2 options: push to followers...

Or let the followers pull the latest tweets

1)Pull()

2)Latest(“tweet1”,”tweet2”,...)



Push

Easier to develop, fewer messagesHow often to push ?

various strategies (immediately, every N new tweets, every X time-unit)

Drawback: how to handle faults of followers ?

xPush(“tweet!”)



Pull

More complex to develop (more messages and handlers, might require slight modifications to message structures and actor state,...)

Same questions than push about pull strategiesBenefit: more tolerant to faults

t1, Pull()

t2, Latest(“tweet!”)



Summary

Actors are a powerful abstractionLeverage message-passing to develop distributed

applicationsActorom provides a simple to use implementation of

the actor model



QUESTIONS?

Actor concurrency for the JVM: a case study

Technology

Transcript of Actor concurrency for the JVM: a case study