View
1.393
Download
0
Category
Preview:
DESCRIPTION
Actors are powerful abstractions to build highly concurrent and scalable applications. We introduce the actor model 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.
Citation preview
{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
{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,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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
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
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
Why do we need actors?
Gordon E. MooreGene Amdahl
No, they're not actors
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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
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
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
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
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
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
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
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
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
Playing ping-pong with actors
First actor implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Playing ping-pong with actors
Second actor implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Playing ping-pong with actors
Messages implementation.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Playing ping-pong with actors
Let the play begin.
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Our case study
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Think: what is Twitter?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Twitter: centralized model
Ciip Ciop
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Does it scale?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
It did not in the past..
2007
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
..and again..
2008
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
..and again..
2009
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
and..
2010
bit.ly/twitter-availability
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
why is this happening?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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
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
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
From Twitter...
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
..to Twittor
?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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 ?
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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
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
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
RegisterMessage
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
RegisterActorHandler
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
FollowMessage
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
FollowHandler
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
FollowResponseMessage
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
FollowResponseHandler
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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”,...)
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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!”)
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
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!”)
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
Summary
Actors are a powerful abstractionLeverage message-passing to develop distributed
applicationsActorom provides a simple to use implementation of
the actor model
{sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma
Javaday IV – Roma – 30 gennaio 2010
QUESTIONS?
Recommended