Actor concurrency for the JVM: a case study
Upcoming SlideShare
Loading in...5
×
 

Actor concurrency for the JVM: a case study

on

  • 1,897 views

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

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.

Statistics

Views

Total Views
1,897
Slideshare-icon Views on SlideShare
1,889
Embed Views
8

Actions

Likes
3
Downloads
38
Comments
1

1 Embed 8

http://www.slideshare.net 8

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Actor concurrency for the JVM: a case study using twitter
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Actor concurrency for the JVM: a case study Actor concurrency for the JVM: a case study Presentation Transcript

    • 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,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. Moore Gene 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.. 20 07 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
    • ..and again.. 20 08 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
    • ..and again.. 20 09 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
    • and.. bit.ly/twitter-availability 20 10 {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 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
    • 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 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
    • 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 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
    • 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 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
    • 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
    • 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
    • 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
    • QUESTIONS? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010