Actor Concurrency Case Study Decentralized Twitter

Actor concurrency for the JVM: a case study

Sergio Bossa, Valerio Schiavoni
Jug Roma

Javaday IV - Roma - 30 gennaio 2010

{sergio.bossa,valerio.schiavoni}@gmail.com, Jug 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


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. Moore
Gene 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..

20
07

..and again..

20
08

..and again..

20
09

and..

bit.ly/twitter-availability

20
10

why is this happening?


Flaws in a centralized design

A centralized model has certain advantages and
a 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 twittor
A twittor has a unique nick
A 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 acts
as 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
To publish, 2 options: push to followers...
Push(“tweet!”)

Or let the followers pull the latest tweets

1)Pull()

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


Push

Easier to develop, fewer messages
How often to push ?
various strategies (immediately, every N new tweets,
every X time-unit)
Drawback: how to handle faults of followers ?

Push(“tweet!”)
x


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 strategies
Benefit: more tolerant to faults
t1, Pull()

t2, Latest(“tweet!”)


Summary

Actors are a powerful abstraction
Leverage message-passing to develop distributed
applications
Actorom provides a simple to use implementation of
the actor model


QUESTIONS?


Actor Concurrency Case Study Decentralized Twitter

Recommended

Recommended

More Related Content

More from vschiavoni

More from vschiavoni (6)

Recently uploaded

Recently uploaded (20)

Actor Concurrency Case Study Decentralized Twitter