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

Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM

We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction.

Akka is here to change that.

Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provides a better platform to build correct concurrent and scalable applications.

For fault-tolerance we adopt the "Let it crash" / "Embrace failure" model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop.

Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.

Akka is Open Source and available under the Apache 2 License.

Jonas Bonér

December 29, 2009
Tweet

More Decks by Jonas Bonér

Other Decks in Programming

Transcript

  1. Jonas Bonér Akka: Simpler Scalability, Fault-tolerance, Concurrency & Remoting through

    Actors http://akkasource.org Scalable Solutions AB Copyright 2009 - Scalable Solutions AB Wednesday, December 30, 2009
  2. What is a Value? A Value is something that does

    not change Discussion based on http://clojure.org/state by Rich Hickey Wednesday, December 30, 2009
  3. What is an Identity? A stable logical entity associated with

    a series of different Values over time Wednesday, December 30, 2009
  4. What is State? The Value an entity with a specific

    Identity has at a particular point in time Wednesday, December 30, 2009
  5. How do we know if something has State? If a

    function is invoked with the same arguments at two different points in time and returns different values... ...then it has state Wednesday, December 30, 2009
  6. The Problem The unification Of Identity & Value They are

    not the same Wednesday, December 30, 2009
  7. We need to separate Identity & Value ...add a level

    of indirection Software Transactional Memory Managed References Message-Passing Concurrency Actors/Active Objects Dataflow Concurrency Dataflow (Single-Assignment) Variables Wednesday, December 30, 2009
  8. Shared-State Concurrency >Concurrent access to shared, mutable state. >Protect mutable

    state with locks >The  Java  C#  C/C++  Ruby  Python  etc. Wednesday, December 30, 2009
  9. Shared-State Concurrency is incredibly hard >Inherently very hard to use

    reliably >Even the experts get it wrong Wednesday, December 30, 2009
  10. Let’s write an atomic transfer method public
class
Account
{ 

... 



public
synchronized
void
transferTo( 





Account
to,
double
amount)
{

    





this.withdraw(amount);

 





to.deposit(amount); 



}

 



... 

} This will work right? Wednesday, December 30, 2009
  11. We need to enforce lock ordering >How? >Java won’t help

    us >Need to use code convention (names etc.) >Requires knowledge about the internal state and implementation of Account >…runs counter to the principles of encapsulation in OOP >Opens up a Can of Worms Wednesday, December 30, 2009
  12. The problem with locks Locks do not compose Taking too

    few locks Taking too many locks Taking the wrong locks Taking locks in the wrong order Error recovery is hard Wednesday, December 30, 2009
  13. Java bet on the wrong horse? Perhaps, but we’re not

    completely screwed There are alternatives Wednesday, December 30, 2009
  14. •Originates in a 1973 paper by Carl Hewitt •Implemented in

    Erlang, Occam, Oz •Encapsulates state and behavior •Closer to the definition of OO than classes Actors Wednesday, December 30, 2009
  15. “OOP to me means only messaging, local retention and protection

    and hiding of state-process, and extreme late-binding of all things.” “Actually I made up the term “object-oriented”, and I can tell you I did not have C++ in mind.” Replace C++ with Java or C# Alan Kay (father of SmallTalk and OOP) Wednesday, December 30, 2009
  16. Actors • Implements Message-Passing Concurrency • Share NOTHING • Isolated

    lightweight processes • Communicates through messages • Asynchronous and non-blocking Wednesday, December 30, 2009
  17. Actor Model of Concurrency • No shared state … hence,

    nothing to synchronize. • Each actor has a mailbox (message queue) Wednesday, December 30, 2009
  18. • Non-blocking send • Blocking receive • Messages are immutable

    • Highly performant and scalable • SEDA-style (Staged Event-Driven Architecture) Actor Model of Concurrency Wednesday, December 30, 2009
  19. Actor Model of Concurrency • Easier to reason about •

    Raised abstraction level • Easier to avoid –Race conditions –Deadlocks –Starvation –Live locks Wednesday, December 30, 2009
  20. Akka Actors • Asynchronous –Fire-and-forget –Futures (Send Receive Reply Eventually)

    • Synchronous • Message loop with pattern (message) matching • Erlang-style Wednesday, December 30, 2009
  21. Two different models • Thread-based • Event-based –Very lightweight –Can

    easily create millions on a single workstation (6.5 million on 4 G RAM) Wednesday, December 30, 2009
  22. > Akka (Java/Scala) > Kilim (Java) > Jetlang (Java) >

    Actor’s Guild (Java) > ActorFoundry (Java) > Actorom (Java) > FunctionalJava (Java) > GParallelizer (Groovy) > Fan Actors (Fan) Actor libs for the JVM Wednesday, December 30, 2009
  23. Akka Transactors Supervisor hierarchies STM Persistent Fault tolerance & Scalablility

    Distributed RESTful Comet Secure Wednesday, December 30, 2009
  24. Thread-based actors • One thread per Actor • Good: •

    Threads (actors) don’t block each other • Good for long-running tasks • Bad: • Poor scalability • Bad for short running tasks • Use for a limited number of Actors • Use for low frequency of messages Wednesday, December 30, 2009
  25. Event-based actors • Backed by thread pool • Lightweight: •

    Can create millions of Actors • 6.5 million on 4 G RAM •Best scalability and performance •2 million messages in 8 seconds Wednesday, December 30, 2009
  26. Single threaded event-based actors •Best performance • Millions of Actors

    •Bad: •one actor can block all other actors •Does not take advantage of multicore Wednesday, December 30, 2009
  27. STM: overview >See the memory (heap and stack) as a

    transactional dataset >Similar to a database  begin  commit  abort/rollback >Transactions are retried automatically upon collision >Rolls back the memory on abort Wednesday, December 30, 2009
  28. > Transactions can nest > Transactions compose (yipee!!) 


atomic
{


 




..




    




atomic
{



 






..



 




}

 


}

 STM: overview Wednesday, December 30, 2009
  29. 92 >All operations in scope of a transaction:  Need

    to be idempotent  Can’t have side-effects STM: restrictions Wednesday, December 30, 2009
  30. 93 Akka STM is based on the ideas of Clojure

    STM Wednesday, December 30, 2009
  31. • Typical OO: direct access to mutable objects Managed References

    Typical OO - Direct references to Mutable Objects • Unifies identity and value • Anything can change at any time • Consistency is a user problem • Encapsulation doesn’t solve concurrency problems ? ? 42 ? 6 :e :d :c :b :a foo • Managed Reference: separates Identity & Value Clojure - Indirect references to Immutable Objects 6 17 "ethel" "fred" 42 :e :d :c :b :a foo @foo • Separates identity and value Copyright Rich Hickey 2009 Wednesday, December 30, 2009
  32. • Separates Identity from Value - Values are immutable -

    Identity (Ref) holds Values • Change is a function • Compare-and-swap (CAS) • Abstraction of time • Can only be altered within a transaction Managed References Wednesday, December 30, 2009
  33. Persistent datastructures • Immutable • Change is a function •

    Old version still available after change • Very fast with performance guarantees (near constant time) • Thread safe • Iteration safe Wednesday, December 30, 2009
  34. Structural sharing with path copying Path Copying int count 15

    INode root HashMap int count 16 INode root HashMap Copyright Rich Hickey 2009 Approach • Programming with values is critical • By eschewing morphing in place, we just need to manage the succession of values (states) of an identity • A timeline coordination problem • Several semantics possible • Managed references • Variable-like cells with coordination semantics Wednesday, December 30, 2009
  35. • Transactional Memory - Atomic, Consistent, Isolated (ACI) - MVCC

    - Rolls back in memory and retries automatically on clash • Works together with Managed References • Map, Vector and Ref abstraction Akka STM Wednesday, December 30, 2009
  36. • Pluggable storage backend - Cassandra - MongoDB - Redis

    • Map, Vector and Ref abstraction • MVCC • Works together with STM Persistence Wednesday, December 30, 2009
  37. Comet actors • Based on Atmosphere project • Portable •

    Supports natively: • Tomcat 4, 5, 6 • Jetty 5, 6, 7 • GlassFish 1, 2, 3 • Weblogic 9.x, 10.x • Grizzly 1.9.x • JBossWeb 2.x • Annotation based Wednesday, December 30, 2009
  38. @Path("/chat") class
Chat
extends
Actor
{ 

case
class
Chat(who:
String,
what:
String,
message:
String) 

@Suspend
//
receiving
endpoint 

@GET
@Produces(Array("text/html")) 

def
suspend
=
<!‐‐
suspend
‐‐> 

//
sending
endpoint 

@Broadcast(Array(classOf[XSSHtmlFilter],
classOf[JsonFilter])) 

@Consumes(Array("application/x‐www‐form‐urlencoded")) 

@Produces(Array("text/html"))

    

@POST
 

def
publishMessage(form:
MultivaluedMap[String,
String])
= 



(this
!!
Chat(form.getFirst("name"),
form.getFirst("action"),

 












form.getFirst("message"))).getOrElse("System
error") 

def
receive
=
{
case
Chat(..)
=>
..} } Comet actors Wednesday, December 30, 2009