Actors are powerful abstractions to build highly concurrent and scalable applications.
We introduce the actor model and and an open-source, pure-java implementation called Actorom.
We then use Actorom for our case-study, where we'll build a fully decentralized Twitter-clone.
Handwritten Text Recognition for manuscripts and early printed texts
Actor concurrency for the JVM: a case study
1. 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
2. Plan
Actor model
Actorom
Case study: decentralized Twitter-clone
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
3. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
4. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
5. 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?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
6. Why do we need actors?
Gordon E. Moore
Gene Amdahl
No, they're not actors
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
7. 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!
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
8. 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.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
9. 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.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
10. 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!
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
11. The actors alternative
Actor concurrency model.
Shared nothing.
Message passing.
Asynchronous.
Simpler.
− Yes, I said: simpler.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
12. 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.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
13. 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.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
14. 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/
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
15. 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.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
16. Playing ping-pong with actors
First actor implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
17. Playing ping-pong with actors
Second actor implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
18. Playing ping-pong with actors
Messages implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
19. Playing ping-pong with actors
Let the play begin.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
28. why is this happening?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
29. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
30. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
31. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
32. 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”
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
34. ..to Twittor
?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
35. 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 ?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
36. Messages, part 1
1) Register(“ugo”,addr)
2) (optional) AckRegister
3) Follow(“ugo”)
4) FollowResponse({“ugo”:addr})
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
37. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
44. 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”,...)
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
45. 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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
46. 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!”)
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
47. Summary
Actors are a powerful abstraction
Leverage message-passing to develop distributed
applications
Actorom provides a simple to use implementation of
the actor model
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
48. QUESTIONS?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010