Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introducing Akka

Jonas Bonér
September 14, 2012

Introducing Akka

We believe that one should never have to choose between productivity
and scalability, which has been the case with traditional approaches
to concurrency and distribution. The cause of that has been the wrong
tools and the wrong layer of abstraction and Akka is here to change
that. Akka is a unified runtime and programming model for scaling both
UP (utilizing multi-core processors) and OUT (utilizing the
grid/cloud). With Akka this will be taken to a whole new level with
its “Distributed by Design”. Akka provides location transparency by
abstracting away both these tangents of scalability by turning them
into an operations and configuration task. This gives the Akka runtime
freedom to do adaptive automatic load-balancing, cluster rebalancing,
replication and partitioning. Akka is available at [http://akka.io]
(under Apache 2 license).

Jonas Bonér

September 14, 2012
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

  1. Introducing
    Jonas Bonér
    CTO Typesafe

    View Slide

  2. Introducing

    View Slide

  3. Introducing
    Akka (Áhkká)
    The name comes from the goddess in the Sami
    (native swedes) mythology that represented all
    the wisdom and beauty in the world.
    It is also the name of a beautiful mountain in
    Laponia in the north part of Sweden

    View Slide

  4. Introducing

    View Slide

  5. Vision
    Simpler
    Concurrency
    Scalability
    Fault-tolerance

    View Slide

  6. Vision
    ...with a single unified
    Programming Model
    Managed Runtime
    Open Source Distribution

    View Slide

  7. Manage System Overload

    View Slide

  8. Scale UP & Scale OUT

    View Slide

  9. Program at a Higher Level

    View Slide

  10. Program at a Higher Level

    View Slide

  11. Program at a Higher Level
    • Never think in terms of shared state, state
    visibility, threads, locks, concurrent collections,
    thread notifications etc.

    View Slide

  12. Program at a Higher Level
    • Never think in terms of shared state, state
    visibility, threads, locks, concurrent collections,
    thread notifications etc.
    • Low level concurrency plumbing BECOMES
    SIMPLE WORKFLOW - you only think about how
    messages flow in the system

    View Slide

  13. Program at a Higher Level
    • Never think in terms of shared state, state
    visibility, threads, locks, concurrent collections,
    thread notifications etc.
    • Low level concurrency plumbing BECOMES
    SIMPLE WORKFLOW - you only think about how
    messages flow in the system
    • You get high CPU utilization, low latency, high
    throughput and scalability - FOR FREE as part of
    the model

    View Slide

  14. Program at a Higher Level
    • Never think in terms of shared state, state
    visibility, threads, locks, concurrent collections,
    thread notifications etc.
    • Low level concurrency plumbing BECOMES
    SIMPLE WORKFLOW - you only think about how
    messages flow in the system
    • You get high CPU utilization, low latency, high
    throughput and scalability - FOR FREE as part of
    the model
    • Proven and superior model for detecting and
    recovering from errors

    View Slide

  15. Distributable by Design

    View Slide

  16. Distributable by Design

    View Slide

  17. Distributable by Design
    • Actors are location transparent & distributable by design

    View Slide

  18. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model

    View Slide

  19. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model
    • You get the PERFECT FABRIC for the CLOUD

    View Slide

  20. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model
    • You get the PERFECT FABRIC for the CLOUD
    - elastic & dynamic

    View Slide

  21. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model
    • You get the PERFECT FABRIC for the CLOUD
    - elastic & dynamic
    - fault-tolerant & self-healing

    View Slide

  22. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model
    • You get the PERFECT FABRIC for the CLOUD
    - elastic & dynamic
    - fault-tolerant & self-healing
    - adaptive load-balancing, cluster rebalancing & actor migration

    View Slide

  23. Distributable by Design
    • Actors are location transparent & distributable by design
    • Scale UP and OUT for free as part of the model
    • You get the PERFECT FABRIC for the CLOUD
    - elastic & dynamic
    - fault-tolerant & self-healing
    - adaptive load-balancing, cluster rebalancing & actor migration
    - build extremely loosely coupled and dynamic systems that can
    change and adapt at runtime

    View Slide

  24. Selection of Akka Production Users

    View Slide

  25. View Slide

  26. How
    can we achieve this?

    View Slide

  27. How
    can we achieve this?

    View Slide

  28. How
    can we achieve this?
    Let’s use Actors

    View Slide

  29. What is an Actor?

    View Slide

  30. What is an Actor?

    View Slide

  31. What is an Actor?
    • Akka's unit of code organization is called an Actor

    View Slide

  32. What is an Actor?
    • Akka's unit of code organization is called an Actor
    • Actors helps you create concurrent, scalable and
    fault-tolerant applications

    View Slide

  33. What is an Actor?
    • Akka's unit of code organization is called an Actor
    • Actors helps you create concurrent, scalable and
    fault-tolerant applications
    • Like Java EE servlets and session beans, Actors is a
    model for organizing your code that keeps many
    “policy decisions” separate from the business logic

    View Slide

  34. What is an Actor?
    • Akka's unit of code organization is called an Actor
    • Actors helps you create concurrent, scalable and
    fault-tolerant applications
    • Like Java EE servlets and session beans, Actors is a
    model for organizing your code that keeps many
    “policy decisions” separate from the business logic
    • Actors may be new to many in the Java community,
    but they are a tried-and-true concept (Hewitt 1973)
    used for many years in telecom systems with 9 nines
    uptime

    View Slide

  35. View Slide

  36. Actors can be seen as
    Virtual Machines (nodes)
    in Cloud Computing

    View Slide

  37. View Slide

  38. Encapsulated
    and decoupled
    black boxes...

    View Slide

  39. Encapsulated
    and decoupled
    black boxes...

    View Slide

  40. View Slide

  41. ...that manages their own
    memory and behavior

    View Slide

  42. ...that manages their own
    memory and behavior

    View Slide

  43. View Slide

  44. Communicates
    with asynchronous
    non-blocking
    messages

    View Slide

  45. Communicates
    with asynchronous
    non-blocking
    messages

    View Slide

  46. View Slide

  47. Elastic - grow and
    shrink on demand

    View Slide

  48. Elastic - grow and
    shrink on demand

    View Slide

  49. Elastic - grow and
    shrink on demand

    View Slide

  50. Elastic - grow and
    shrink on demand

    View Slide

  51. View Slide

  52. Hot deploy - change
    behavior at runtime

    View Slide

  53. Hot deploy - change
    behavior at runtime

    View Slide

  54. Now - if we replace
    with
    Actor
    EVERYTHING will STILL HOLD for both
    LOCAL and DISTRIBUTED Actors

    View Slide

  55. What can I use Actors for?

    View Slide

  56. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:

    View Slide

  57. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread

    View Slide

  58. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component

    View Slide

  59. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener

    View Slide

  60. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener
    - a singleton or service

    View Slide

  61. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener
    - a singleton or service
    - a router, load-balancer or pool

    View Slide

  62. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener
    - a singleton or service
    - a router, load-balancer or pool
    - a Java EE Session Bean or Message-Driven Bean

    View Slide

  63. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener
    - a singleton or service
    - a router, load-balancer or pool
    - a Java EE Session Bean or Message-Driven Bean
    - an out-of-process service

    View Slide

  64. What can I use Actors for?
    In different scenarios, an Actor may be an
    alternative to:
    - a thread
    - an object instance or component
    - a callback or listener
    - a singleton or service
    - a router, load-balancer or pool
    - a Java EE Session Bean or Message-Driven Bean
    - an out-of-process service
    - a Finite State Machine (FSM)

    View Slide

  65. So, what is the
    Actor Model?

    View Slide

  66. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors

    View Slide

  67. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:

    View Slide

  68. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing

    View Slide

  69. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage

    View Slide

  70. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage
    - Communication

    View Slide

  71. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage
    - Communication
    - 3 axioms - When an Actor receives a message it can:

    View Slide

  72. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage
    - Communication
    - 3 axioms - When an Actor receives a message it can:
    - Create new Actors

    View Slide

  73. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage
    - Communication
    - 3 axioms - When an Actor receives a message it can:
    - Create new Actors
    - Send messages to Actors it knows

    View Slide

  74. Carl Hewitt’s definition
    http://bit.ly/hewitt-on-actors
    - The fundamental unit of computation that embodies:
    - Processing
    - Storage
    - Communication
    - 3 axioms - When an Actor receives a message it can:
    - Create new Actors
    - Send messages to Actors it knows
    - Designate how it should handle the next message it receives

    View Slide

  75. 4 core Actor operations
    0. DEFINE
    1. CREATE
    2. SEND
    3. BECOME
    4. SUPERVISE

    View Slide

  76. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    0. DEFINE

    View Slide

  77. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    0. DEFINE
    Define the message(s) the Actor
    should be able to respond to

    View Slide

  78. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    0. DEFINE
    Define the message(s) the Actor
    should be able to respond to
    Define the Actor class

    View Slide

  79. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    0. DEFINE
    Define the message(s) the Actor
    should be able to respond to
    Define the Actor class
    Define the Actor’s behavior

    View Slide

  80. case class Greeting(who: String)
    class GreetingActor extends Actor with ActorLogging {
    def receive = {
    case Greeting(who) => log.info("Hello {}", who)
    }
    }
    Scala version

    View Slide

  81. 1. CREATE
    •CREATE - creates a new instance of an Actor
    •Extremely lightweight (2.7 Million per Gb RAM)
    •Very strong encapsulation - encapsulates:
    - state
    - behavior
    - message queue
    •State & behavior is indistinguishable from each other
    •Only way to observe state is by sending an actor a
    message and see how it reacts

    View Slide

  82. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor

    View Slide

  83. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor
    Create an Actor system

    View Slide

  84. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor
    Create an Actor system Actor configuration

    View Slide

  85. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor
    Create an Actor system Actor configuration
    Give it a name

    View Slide

  86. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor
    Create an Actor system
    Create the Actor
    Actor configuration
    Give it a name

    View Slide

  87. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    CREATE Actor
    Create an Actor system
    Create the Actor
    Actor configuration
    Give it a name
    You get an ActorRef back

    View Slide

  88. Guardian System Actor
    Actors can form hierarchies

    View Slide

  89. Guardian System Actor
    system.actorOf(Props[Foo], “Foo”)
    Actors can form hierarchies

    View Slide

  90. Foo
    Guardian System Actor
    system.actorOf(Props[Foo], “Foo”)
    Actors can form hierarchies

    View Slide

  91. Foo
    Guardian System Actor
    context.actorOf(Props[A], “A”)
    Actors can form hierarchies

    View Slide

  92. A
    Foo
    Guardian System Actor
    context.actorOf(Props[A], “A”)
    Actors can form hierarchies

    View Slide

  93. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    Guardian System Actor
    Actors can form hierarchies

    View Slide

  94. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    Guardian System Actor
    Name resolution - like a file-system

    View Slide

  95. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    /Foo
    Guardian System Actor
    Name resolution - like a file-system

    View Slide

  96. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    /Foo
    /Foo/A
    Guardian System Actor
    Name resolution - like a file-system

    View Slide

  97. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    /Foo
    /Foo/A
    /Foo/A/B
    Guardian System Actor
    Name resolution - like a file-system

    View Slide

  98. A
    B
    Bar
    Foo
    C
    B
    E
    A
    D
    C
    /Foo
    /Foo/A
    /Foo/A/B
    /Foo/A/D
    Guardian System Actor
    Name resolution - like a file-system

    View Slide

  99. 2. SEND

    View Slide

  100. 2. SEND
    •SEND - sends a message to an Actor

    View Slide

  101. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget

    View Slide

  102. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget
    •Everything happens Reactively

    View Slide

  103. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget
    •Everything happens Reactively
    - An Actor is passive until a message is sent to it,
    which triggers something within the Actor

    View Slide

  104. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget
    •Everything happens Reactively
    - An Actor is passive until a message is sent to it,
    which triggers something within the Actor
    - Messages is the Kinetic Energy in an Actor system

    View Slide

  105. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget
    •Everything happens Reactively
    - An Actor is passive until a message is sent to it,
    which triggers something within the Actor
    - Messages is the Kinetic Energy in an Actor system
    - Actors can have lots of buffered Potential Energy
    but can't do anything with it until it is triggered by
    a message

    View Slide

  106. 2. SEND
    •SEND - sends a message to an Actor
    •Asynchronous and Non-blocking - Fire-forget
    •Everything happens Reactively
    - An Actor is passive until a message is sent to it,
    which triggers something within the Actor
    - Messages is the Kinetic Energy in an Actor system
    - Actors can have lots of buffered Potential Energy
    but can't do anything with it until it is triggered by
    a message
    •EVERYTHING is asynchronous and lockless

    View Slide

  107. Throughput on a single box
    +50 million messages per second

    View Slide

  108. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    greeter.tell(new Greeting("Charlie Parker"));
    SEND message

    View Slide

  109. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    greeter.tell(new Greeting("Charlie Parker"));
    SEND message
    Send the message

    View Slide

  110. public class Greeting implements Serializable {
    public final String who;
    public Greeting(String who) { this.who = who; }
    }
    public class GreetingActor extends UntypedActor {
    LoggingAdapter log = Logging.getLogger(getContext().system(), this);
    public void onReceive(Object message) throws Exception {
    if (message instanceof Greeting)
    log.info("Hello {}", ((Greeting) message).who);
    }
    }
    }
    ActorSystem system = ActorSystem.create("MySystem");
    ActorRef greeter = system.actorOf(new Props(GreetingActor.class), "greeter");
    greeter.tell(new Greeting("Charlie Parker"));
    Full example

    View Slide

  111. case class Greeting(who: String)
    class GreetingActor extends Actor with ActorLogging {
    def receive = {
    case Greeting(who) => log.info("Hello {}", who)
    }
    }
    val system = ActorSystem("MySystem")
    val greeter = system.actorOf(Props[GreetingActor], name = "greeter")
    greeter tell Greeting("Charlie Parker")
    Scala version

    View Slide

  112. class SomeActor extends UntypedActor {
    void onReceive(Object msg) {
    if (msg instanceof User) {
    User user = (User) msg;
    // reply to sender
    getSender().tell(“Hi ” + user.name);
    }
    }
    }
    Reply

    View Slide

  113. class SomeActor extends Actor {
    def receive = {
    case User(name) =>
    // reply to sender
    sender tell (“Hi ” + name)
    }
    }
    Scala version

    View Slide

  114. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Remote deployment

    View Slide

  115. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Remote deployment

    View Slide

  116. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    For the Greeter actor
    Remote deployment

    View Slide

  117. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Define Remote Path
    For the Greeter actor
    Remote deployment

    View Slide

  118. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Define Remote Path Protocol
    For the Greeter actor
    akka://
    Remote deployment

    View Slide

  119. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Define Remote Path Protocol Actor System
    For the Greeter actor
    akka://MySystem
    Remote deployment

    View Slide

  120. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Define Remote Path Protocol Actor System Hostname
    For the Greeter actor
    akka://[email protected]
    Remote deployment

    View Slide

  121. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Configure a Remote Provider
    Define Remote Path Protocol Actor System Hostname Port
    For the Greeter actor
    akka://[email protected]:2552
    Remote deployment

    View Slide

  122. akka {
    actor {
    provider = akka.remote.RemoteActorRefProvider
    deployment {
    /Greeter {
    remote =
    }
    }
    }
    }
    Just feed the ActorSystem with this configuration
    Zero code changes
    Configure a Remote Provider
    Define Remote Path Protocol Actor System Hostname Port
    For the Greeter actor
    akka://[email protected]:2552
    Remote deployment

    View Slide

  123. 3. BECOME

    View Slide

  124. 3. BECOME
    •BECOME - dynamically redefines Actor’s behavior

    View Slide

  125. 3. BECOME
    •BECOME - dynamically redefines Actor’s behavior
    •Triggered reactively by receive of message

    View Slide

  126. 3. BECOME
    •BECOME - dynamically redefines Actor’s behavior
    •Triggered reactively by receive of message
    •In a type system analogy it is as if the object changed
    type - changed interface, protocol & implementation

    View Slide

  127. 3. BECOME
    •BECOME - dynamically redefines Actor’s behavior
    •Triggered reactively by receive of message
    •In a type system analogy it is as if the object changed
    type - changed interface, protocol & implementation
    •Will now react differently to the messages it receives

    View Slide

  128. 3. BECOME
    •BECOME - dynamically redefines Actor’s behavior
    •Triggered reactively by receive of message
    •In a type system analogy it is as if the object changed
    type - changed interface, protocol & implementation
    •Will now react differently to the messages it receives
    •Behaviors are stacked & can be pushed and popped

    View Slide

  129. Why would I want to do that?

    View Slide

  130. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router

    View Slide

  131. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router
    •Implement an FSM (Finite State Machine)

    View Slide

  132. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router
    •Implement an FSM (Finite State Machine)
    •Implement graceful degradation

    View Slide

  133. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router
    •Implement an FSM (Finite State Machine)
    •Implement graceful degradation
    •Spawn up (empty) generic Worker processes that
    can become whatever the Master currently needs

    View Slide

  134. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router
    •Implement an FSM (Finite State Machine)
    •Implement graceful degradation
    •Spawn up (empty) generic Worker processes that
    can become whatever the Master currently needs
    •etc. use your imagination

    View Slide

  135. Why would I want to do that?
    •Let a highly contended Actor adaptively transform
    himself into an Actor Pool or a Router
    •Implement an FSM (Finite State Machine)
    •Implement graceful degradation
    •Spawn up (empty) generic Worker processes that
    can become whatever the Master currently needs
    •etc. use your imagination
    •Very useful once you get the used to it

    View Slide

  136. context.become(new Procedure[Object]() {
    void apply(Object msg) {
    // new body
    if (msg instanceof NewMessage) {
    NewMessage newMsg = (NewMessage)msg;
    ...
    }
    }
    });
    become

    View Slide

  137. context.become(new Procedure[Object]() {
    void apply(Object msg) {
    // new body
    if (msg instanceof NewMessage) {
    NewMessage newMsg = (NewMessage)msg;
    ...
    }
    }
    });
    Actor context available
    from within an Actor
    become

    View Slide

  138. context become {
    // new body
    case NewMessage =>
    ...
    }
    Scala version

    View Slide

  139. Load Balancing

    View Slide

  140. Routers
    val router =
    system.actorOf(
    Props[SomeActor].withRouter(
    RoundRobinRouter(nrOfInstances = 5)))
    Scala API

    View Slide

  141. Router + Resizer
    val resizer =
    DefaultResizer(lowerBound = 2, upperBound = 15)
    val router =
    system.actorOf(
    Props[ExampleActor1].withRouter(
    RoundRobinRouter(resizer = Some(resizer))))
    Scala API

    View Slide

  142. Failure management in Java/C/C# etc.

    View Slide

  143. • You are given a SINGLE thread of control
    Failure management in Java/C/C# etc.

    View Slide

  144. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    Failure management in Java/C/C# etc.

    View Slide

  145. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    Failure management in Java/C/C# etc.

    View Slide

  146. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    • To make things worse - errors do not propagate
    between threads so there is NO WAY OF EVEN
    FINDING OUT that something have failed
    Failure management in Java/C/C# etc.

    View Slide

  147. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    • To make things worse - errors do not propagate
    between threads so there is NO WAY OF EVEN
    FINDING OUT that something have failed
    • This leads to DEFENSIVE programming with:
    Failure management in Java/C/C# etc.

    View Slide

  148. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    • To make things worse - errors do not propagate
    between threads so there is NO WAY OF EVEN
    FINDING OUT that something have failed
    • This leads to DEFENSIVE programming with:
    • Error handling TANGLED with business logic
    Failure management in Java/C/C# etc.

    View Slide

  149. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    • To make things worse - errors do not propagate
    between threads so there is NO WAY OF EVEN
    FINDING OUT that something have failed
    • This leads to DEFENSIVE programming with:
    • Error handling TANGLED with business logic
    • SCATTERED all over the code base
    Failure management in Java/C/C# etc.

    View Slide

  150. • You are given a SINGLE thread of control
    • If this thread blows up you are screwed
    • So you need to do all explicit error handling
    WITHIN this single thread
    • To make things worse - errors do not propagate
    between threads so there is NO WAY OF EVEN
    FINDING OUT that something have failed
    • This leads to DEFENSIVE programming with:
    • Error handling TANGLED with business logic
    • SCATTERED all over the code base
    We can do better than this!!!
    Failure management in Java/C/C# etc.

    View Slide

  151. 4. SUPERVISE

    View Slide

  152. 4. SUPERVISE
    •SUPERVISE - manage another Actor’s failures

    View Slide

  153. 4. SUPERVISE
    •SUPERVISE - manage another Actor’s failures
    •Error handling in actors is handle by letting Actors
    monitor (supervise) each other for failure

    View Slide

  154. 4. SUPERVISE
    •SUPERVISE - manage another Actor’s failures
    •Error handling in actors is handle by letting Actors
    monitor (supervise) each other for failure
    •This means that if an Actor crashes, a notification
    will be sent to his supervisor, who can react upon
    the failure

    View Slide

  155. 4. SUPERVISE
    •SUPERVISE - manage another Actor’s failures
    •Error handling in actors is handle by letting Actors
    monitor (supervise) each other for failure
    •This means that if an Actor crashes, a notification
    will be sent to his supervisor, who can react upon
    the failure
    •This provides clean separation of processing and
    error handling

    View Slide

  156. ...let’s take a
    standard OO
    application

    View Slide

  157. View Slide

  158. Which components have
    critically important state
    and
    explicit error handling?

    View Slide

  159. View Slide

  160. Fault-tolerant
    onion-layered
    Error Kernel

    View Slide

  161. Error
    Kernel

    View Slide

  162. Error
    Kernel

    View Slide

  163. Error
    Kernel

    View Slide

  164. Error
    Kernel

    View Slide

  165. Error
    Kernel

    View Slide

  166. Error
    Kernel

    View Slide

  167. Error
    Kernel
    Node 1 Node 2

    View Slide

  168. SUPERVISE Actor
    Every single actor has a
    default supervisor strategy.
    Which is usually sufficient.
    But it can be overridden.

    View Slide

  169. class Supervisor extends UntypedActor {
    private SupervisorStrategy strategy = new OneForOneStrategy(
    10,
    Duration.parse("1 minute"),
    new Function() {
    @Override public Directive apply(Throwable t) {
    if (t instanceof ArithmeticException) return resume();
    else if (t instanceof NullPointerException) return restart();
    else return escalate();
    }
    });
    @Override public SupervisorStrategy supervisorStrategy() {
    SUPERVISE Actor
    Every single actor has a
    default supervisor strategy.
    Which is usually sufficient.
    But it can be overridden.

    View Slide

  170. class Supervisor extends UntypedActor {
    private SupervisorStrategy strategy = new OneForOneStrategy(
    10,
    Duration.parse("1 minute"),
    new Function() {
    @Override public Directive apply(Throwable t) {
    if (t instanceof ArithmeticException) return resume();
    else if (t instanceof NullPointerException) return restart();
    else return escalate();
    }
    });
    @Override public SupervisorStrategy supervisorStrategy() {
    return strategy;
    }
    ActorRef worker = context.actorOf(new Props(Worker.class));
    public void onReceive(Object message) throws Exception {
    if (message instanceof Integer) worker.forward(message);
    }
    }
    SUPERVISE Actor

    View Slide

  171. class Supervisor extends Actor {
    override val supervisorStrategy =
    (maxNrOfRetries = 10, withinTimeRange = 1 minute) {
    case _: ArithmeticException => Resume
    case _: NullPointerException => Restart
    case _: Exception => Escalate
    }
    val worker = context.actorOf(Props[Worker])
    def receive = {
    case n: Int => worker forward n
    }
    }
    Scala version

    View Slide

  172. class Supervisor extends Actor {
    override val supervisorStrategy =
    (maxNrOfRetries = 10, withinTimeRange = 1 minute) {
    case _: ArithmeticException => Resume
    case _: NullPointerException => Restart
    case _: Exception => Escalate
    }
    val worker = context.actorOf(Props[Worker])
    def receive = {
    case n: Int => worker forward n
    }
    }
    Scala version
    OneForOneStrategy

    View Slide

  173. class Supervisor extends Actor {
    override val supervisorStrategy =
    (maxNrOfRetries = 10, withinTimeRange = 1 minute) {
    case _: ArithmeticException => Resume
    case _: NullPointerException => Restart
    case _: Exception => Escalate
    }
    val worker = context.actorOf(Props[Worker])
    def receive = {
    case n: Int => worker forward n
    }
    }
    Scala version
    AllForOneStrategy

    View Slide

  174. class Worker extends Actor {
    ...
    override def preRestart(
    reason: Throwable, message: Option[Any]) {
    ... // clean up before restart
    }
    override def postRestart(reason: Throwable) {
    ... // init after restart
    }
    }
    Manage failure
    Scala API

    View Slide

  175. This was
    Akka 2.x

    View Slide

  176. This was
    Akka 2.x
    Well...it’s a start...

    View Slide

  177. ...we have much much more

    View Slide

  178. AMQP
    Dataflow
    ...we have much much more
    Cluster FSM
    Transactors
    Spring
    Pub/Sub
    ZeroMQ
    Microkernel
    IO
    TestKit
    Agents
    SLF4J
    Durable Mailboxes
    EventBus
    Camel
    TypedActor
    Extensions
    HTTP/REST

    View Slide

  179. get it and learn more
    http://akka.io
    http://typesafe.com
    http://letitcrash.com

    View Slide

  180. EOF

    View Slide