Actor concurrency for the JVM: a case study

2,239 views
2,164 views

Published on

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.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,239
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
46
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Actor concurrency for the JVM: a case study

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Playing ping-pong with actors First actor implementation. {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  17. 17. Playing ping-pong with actors Second actor implementation. {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  18. 18. Playing ping-pong with actors Messages implementation. {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  19. 19. Playing ping-pong with actors Let the play begin. {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  20. 20. Our case study {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  21. 21. Think: what is Twitter? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  22. 22. Twitter: centralized model Ciip Ciop {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  23. 23. Does it scale? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  24. 24. It did not in the past.. 20 07 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  25. 25. ..and again.. 20 08 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  26. 26. ..and again.. 20 09 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  27. 27. and.. bit.ly/twitter-availability 20 10 {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  28. 28. why is this happening? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  29. 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. 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. 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. 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
  33. 33. From Twitter... {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  34. 34. ..to Twittor ? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  35. 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. 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. 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
  38. 38. RegisterMessage {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  39. 39. RegisterActorHandler {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  40. 40. FollowMessage {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  41. 41. FollowHandler {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  42. 42. FollowResponseMessage {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  43. 43. FollowResponseHandler {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010
  44. 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. 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. 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. 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. 48. QUESTIONS? {sergio.bossa,valerio.schiavoni}@gmail.com, Jug Roma Javaday IV – Roma – 30 gennaio 2010

×