Akka london scala_user_group

Akka: Simpler Concurrency, Scalability & Fault-tolerance through Actors Jonas Bonér Scalable Solutions jonas@jonasboner.com twitter: @jboner

The problem It is way too hard to build: 1. correct highly concurrent systems 2. truly scalable systems 3. fault-tolerant systems that self-heal ...using “state-of-the-art” tools

Why so difﬁcult ? • We have been doing things the same way for so long, threads, locks... • Enterprise solutions are inﬂexible and unwieldy • Too much code to write

Vision Simpler Concurrency Scalability Fault-tolerance Through one single uniﬁed Programming model Runtime service

Manage system overload

Scale up & Scale out

Replicate and distribute for fault-tolerance

Automatic & adaptive load balancing

Introducing Concurrency Scalability Fault-tolerance Actors STM Agents Dataﬂow Distributed Secure Persistent Open Source Clustered

Architecture Core Modules

Architecture Add-on Modules Add-on Modules

Architecture Enterprise Modules

Actors one tool in the toolbox

Akka Actors

Actor Model of Concurrency • Implements Message-Passing Concurrency • Share NOTHING • Isolated lightweight processes • Communicates through messages • Asynchronous and non-blocking • Each actor has a mailbox (message queue)

Actor Model of Concurrency • Easier to reason about • Raised abstraction level • Easier to avoid –Race conditions –Deadlocks –Starvation –Live locks

Two different models • Thread-based • Event-based – Very lightweight (600 bytes per actor) – Can easily create millions on a single workstation (13 million on 8 G RAM) – Does not consume a thread

Actors case object Tick class Counter extends Actor {   private var counter = 0   def receive = {     case Tick =>        counter += 1       println(counter)   } }

Create Actors import Actor._ val counter = actorOf[Counter] counter is an ActorRef

Create Actors val actor = actorOf(new MyActor(..)) create actor with constructor arguments

Start actors val counter = actorOf[Counter] counter.start

Start actors val counter = actorOf[Counter].start

Stop actors val counter = actorOf[Counter].start counter.stop

preStart & postStop callbacks class MyActor extends Actor {   override def preStart = {     ... // called before ‘start’    }   override def postStop = {     ... // called after ‘stop’   } }

the self reference class RecursiveActor extends Actor {   private var counter = 0   self.id = “service:recursive”   def receive = {     case Tick =>        counter += 1       self ! Tick   } }

Send: ! counter ! Tick  ﬁre-forget

Send: ! counter.sendOneWay(Tick) ﬁre-forget

Send: !! val result = (actor !! Message).as[String] uses Future under the hood (with time-out)

Send: !! val result = counter.sendRequestReply(Tick) uses Future under the hood (with time-out)

Send: !!! // returns a future val future = actor !!! Message future.await val result = future.get ... Futures.awaitOne(List(fut1, fut2, ...)) Futures.awaitAll(List(fut1, fut2, ...)) returns the Future directly

Send: !!! val result = counter.sendRequestReplyFuture(Tick) returns the Future directly

Reply class SomeActor extends Actor {   def receive = {     case User(name) =>        // use reply       self.reply(“Hi ” + name)   } }

Reply class SomeActor extends Actor {   def receive = {     case User(name) =>        // store away the sender       // to use later or        // somewhere else       ... = self.sender   } }

Reply class SomeActor extends Actor {   def receive = {     case User(name) =>        // store away the sender future       // to resolve later or        // somewhere else       ... = self.senderFuture   } }

Immutable messages // define the case class case class Register(user: User) // create and send a new case class message actor ! Register(user) // tuples actor ! (username, password) // lists actor ! List(“bill”, “bob”, “alice”)

ActorRegistry val actors = ActorRegistry.actors val actors = ActorRegistry.actorsFor[TYPE] val actors = ActorRegistry.actorsFor(id) val actor = ActorRegistry.actorFor(uuid) ActorRegistry.foreach(fn) ActorRegistry.shutdownAll

A Case Study Thatcham Integrated Methods The problem: • provide realtime repair information for over 21,000 vehicles • provide accurate, safe repair details on more than 7,000 methods • each document is tailored speciﬁcally for an individual repair / replacement job • too many permutations for caching (at least for phase 1) • a relatively long running process involving IO • a global solution (UK, Europe, USA, Asia, Australasia) • zero downtime allowed

A Case Study The current simple solution: • Akka actors to the rescue • in this case delegation is literally the art of good workload management • two actors sharing the work for each document type • two servers cover a large percentage of the UK penetration • simple load balancing

A Case Study Simple Architecture

A Case Study Conclusion: We originally had a homegrown solution extending Scala actors. What do Akka actors give us ? • the fastest actors implementation • where is the code ? • great stability • massive integration potential • zero downtime • 50-60 documents per minute with our largest document size

A Case Study What next ? • intelligent adaptive load balancing with Akka • enterprise monitoring • Akka in EC2 ? • caching with intelligent swarms of actors in a cluster

TypedActor

Typed Actors class CounterImpl    extends TypedActor with Counter {   private var counter = 0;   def count = {     counter += 1     println(counter)   } }

Create Typed Actor val counter = TypedActor.newInstance(     classOf[Counter], classof[CounterImpl])

Send message counter.count ﬁre-forget

Request Reply val hits = counter.getNrOfHits uses Future under the hood (with time-out)

the context reference class PingImpl extends TypedActor    with Ping {   def hit(count: Int) = {     val pong = getContext   .getSender.asInstanceOf[Pong]     pong.hit(count += 1)   } }

Actors: conﬁg akka {   version = "0.10"   time‐unit = "seconds"   actor {     timeout = 5     throughput = 5   } }

Scalability Benchmark Simple Trading system • Synchronous Scala version • Scala Library Actors 2.8.0 •Fire-forget •Request-reply (Futures) • Akka • Fire-forget (Hawt dispatcher) • Fire-forget (default dispatcher) • Request-reply Run it yourself: http://github.com/patriknw/akka-sample-trading

Agents yet another tool in the toolbox

Agents val agent = Agent(5) // send function asynchronously agent send (_ + 1)  val result = agent() // deref ... // use result agent.close Cooperates with STM

Akka Dispatchers

Dispatchers • Executor-based Dispatcher • Executor-based Work-stealing Dispatcher • Hawt Dispatcher • Thread-based Dispatcher

Dispatchers object Dispatchers {   object globalHawtDispatcher extends HawtDispatcher   ...     def newExecutorBasedEventDrivenDispatcher(name: String)   def newExecutorBasedEventDrivenWorkStealingDispatcher(name: String)   def newHawtDispatcher(aggregate: Boolean)   ... }

Set dispatcher class MyActor extends Actor {   self.dispatcher = Dispatchers     .newThreadBasedDispatcher(self)      ... } actor.dispatcher = dispatcher // before started

Let it crash fault-tolerance

Inﬂuenced by Erlang

9 nines

OneForOne fault handling strategy

AllForOne fault handling strategy

Supervisor hierarchies

Fault handlers AllForOneStrategy(   List(classOf[Throwable]),   maxNrOfRetries,    withinTimeRange) OneForOneStrategy(   List(classOf[Throwable]),   maxNrOfRetries,    withinTimeRange)

Fault handlers AllForOneStrategy(   List(classOf[ServiceException],         classOf[PersistenceException]),   5, 5000)

Linking link(actor)  unlink(actor)  startLink(actor) spawnLink[MyActor]

Supervision class Supervisor extends Actor {   faultHandler = OneForOneStrategy(     List(classOf[Throwable])      5, 5000))   def receive = {     case Register(actor) =>        link(actor)   } }

Manage failure class FaultTolerantService extends Actor {   ...   override def preRestart(reason: Throwable) = {     ... // clean up before restart   }   override def postRestart(reason: Throwable) = {     ... // init after restart   } }

Remote Actors

Remote Server // use host & port in config RemoteNode.start RemoteNode.start("localhost", 9999) Scalable implementation based on NIO (Netty) & Protobuf

Two types of remote actors Client managed Server managed

Client-managed supervision works across nodes // methods in Actor class spawnRemote[MyActor](host, port)  spawnLinkRemote[MyActor](host, port) startLinkRemote(actor, host, port)

Client-managed moves actor to server client manages through proxy val actorProxy = spawnLinkRemote[MyActor](   “darkstar”,    9999) actorProxy ! message

Server-managed register and manage actor on server client gets “dumb” proxy handle RemoteNode.register(“service:id”, actorOf[MyService]) server part

Server-managed val handle = RemoteClient.actorFor(   “service:id”,    “darkstar”,    9999) handle ! message client part

Cluster Membership Cluster.relayMessage(   classOf[TypeOfActor], message) for (endpoint <‐ Cluster)    spawnRemote[TypeOfActor](                 endpoint.host,                endpoint.port)

A Case Study Eventually everything - auditing and logging The problem: • log/audit many operations over a diverse architecture • ensure we get massive reuse across diverse projects internal and external • promote store agnosticism • make the log repository searchable • provide an API for reporting

A Case Study The current simple solution: • Akka remote (server-managed) actors to the rescue • in this case delegation across the network is literally the art of good workload management • ‘free your domain’ by deﬁning your domain ‘verbs’ using simple case classes • further ‘free your domain’ with a clear divide between a simple service, and asynchronous pluggable repositories

A Case Study Minimally intrusive No lethal injections of persistence concerns Pluggable repositories

A Case Study Conclusion: What do Akka remote actors give us ? • simple distribution of operations over the network • decouple concerns to improve our focus on the service/API • great stability • no boilerplate

STM yet another tool in the toolbox

What is STM? 80

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

Managed References • Separates Identity from Value - Values are immutable - Identity (Ref) holds Values • Change is a function • Compare-and-swap (CAS) • Abstraction of time • Must be used within a transaction

atomic import se.scalablesolutions.akka.stm.local._   atomic {   ...   atomic {     ... // transactions compose!!!   } }

Managed References Typical OO - Direct Typical OO: direct Mutable Objects objects references to access to mutable foo :a ? :b ? :c 42 :d ? :e 6 Clojure - and value • Uniﬁes identity Indirect references Managed Reference: separates Identity & Value • Anything can change at any time • Consistency is a user problem Objects to Immutable • Encapsulation doesn’t solve concurrency:a foo "fred" problems :b "ethel" @foo :c 42 :d 17 :e 6 Copyright Rich Hickey 2009

Managed References • Separates Identity from Value - Values are immutable - Identity (Ref) holds Values • Change is a function • Compare-and-swap (CAS) • Abstraction of time • Must be used within a transaction

Managed References import se.scalablesolutions.akka.stm.local._   // giving an initial value val ref = Ref(0)   // specifying a type but no initial value val ref = Ref[Int]

Managed References val ref = Ref(0)   atomic {   ref.set(5) } // ‐> 0   atomic {   ref.get } // ‐> 5

Managed References val ref = Ref(0)   atomic {   ref alter (_ + 5) } // ‐> 5   val inc = (i: Int) => i + 1   atomic {   ref alter inc } // ‐> 6

Managed References val ref = Ref(1)  val anotherRef = Ref(3)   atomic {   for {     value1 <‐ ref     value2 <‐ anotherRef   } yield (value1 + value2) } // ‐> Ref(4)   val emptyRef = Ref[Int]   atomic {   for {     value1 <‐ ref     value2 <‐ emptyRef   } yield (value1 + value2) } // ‐> Ref[Int]

Transactional datastructures // using initial values val map    = TransactionalMap("bill" ‐> User("bill")) val vector = TransactionalVector(Address("somewhere"))   // specifying types val map    = TransactionalMap[String, User] val vector = TransactionalVector[Address]

life-cycle listeners atomic {   deferred {     // executes when transaction commits   }   compensating {     // executes when transaction aborts   } }

Actors + STM = Transactors

Transactors class UserRegistry extends Transactor {      private lazy val storage =      TransactionalMap[String, User]()   def receive = {     case NewUser(user) =>       storage + (user.name ‐> user)     ...    } }

Transactors

Transactors Start transaction

Transactors Start transaction Send message

Transactors Start transaction Send message Update state within transaction

Transactors Start transaction Send message Update state within transaction Transaction fails

Transactors

Transactors Transaction automatically retried

blocking transactions class Transferer extends Actor {   implicit val txFactory = TransactionFactory(     blockingAllowed = true, trackReads = true, timeout = 60 seconds)     def receive = {     case Transfer(from, to, amount) =>       atomic {         if (from.get < amount) {           log.info("not enough money ‐ retrying")           retry         }         log.info("transferring")         from alter (_ ‐ amount)         to alter (_ + amount)       }   } }

either-orElse   atomic {     either {       if (left.get < amount) {         log.info("not enough on left ‐ retrying")         retry       }       log.info("going left")     } orElse {       if (right.get < amount) {         log.info("not enough on right ‐ retrying")         retry       }       log.info("going right")     }   }

STM: conﬁg akka {   stm {       max‐retries = 1000       timeout = 10       write‐skew = true       blocking‐allowed = false       interruptible = false       speculative = true       quick‐release = true       propagation = requires       trace‐level = none       hooks = true       jta‐aware = off   } }

Modules

Akka Persistence

STM gives us Atomic Consistent Isolated

Persistence module turns STM into Atomic Consistent Isolated Durable

Akka Persistence API • Cassandra • HBase • Voldemort • Redis • MongoDB • CouchDB • Any JTA-compliant JDBC driver or ORM

Akka Persistence API // transactional Cassandra‐backed Map  val map = CassandraStorage.newMap // transactional Redis‐backed Vector  val vector = RedisStorage.newVector // transactional Mongo‐backed Ref val ref = MongoStorage.newRef

For Redis only (so far) val queue: PersistentQueue[ElementType] =      RedisStorage.newQueue val set: PersistentSortedSet[ElementType] =   RedisStorage.newSortedSet

Akka Spring

Spring integration <beans>   <akka:typed‐actor      id="myActiveObject"      interface="com.biz.MyPOJO"      implementation="com.biz.MyPOJO"      transactional="true"      timeout="1000" />   ... </beans>

Spring integration <akka:supervision id="my‐supervisor">   <akka:restart‐strategy failover="AllForOne"                           retries="3"                           timerange="1000">     <akka:trap‐exits>     <akka:trap‐exit>java.io.IOException</akka:trap‐exit>     </akka:trap‐exits>   </akka:restart‐strategy>   <akka:typed‐actors>     <akka:typed‐actor interface="com.biz.MyPOJO"                        implementation="com.biz.MyPOJOImpl"                        lifecycle="permanent"                        timeout="1000">     </akka:typed‐actor>   </akka:typed‐actors> </akka:supervision>

Akka Camel

Camel: consumer class MyConsumer extends Actor with Consumer {   def endpointUri = "file:data/input"     def receive = {     case msg: Message =>        log.info("received %s" format       msg.bodyAs(classOf[String]))   } }

Camel: consumer class MyConsumer extends Actor with Consumer {   def endpointUri =      "jetty:http://0.0.0.0:8877/camel/test"     def receive = {     case msg: Message =>        reply("Hello %s" format              msg.bodyAs(classOf[String]))   } }

Camel: producer class CometProducer    extends Actor with Producer {      def endpointUri =      "cometd://localhost:8111/test" }

Camel: producer val producer = actorOf[CometProducer].start val time = "Current time: " + new Date producer ! time

Akka HotSwap

HotSwap actor ! HotSwap({   // new body   case Ping =>      ...    case Pong =>      ...   })

HotSwap self.become({   // new body   case Ping =>      ...    case Pong =>      ...   })

Akka Concurrent Problem Solving

Simple Use Cases • Use different actors to compose computations and have them calculated in parallel • Analyse sequential versus non sequential operations • For simple isolated tasks start up more actors to reduce your message box size • Wherever possible share nothing, then you have no coupling or dependencies you can just scale out to inﬁnity

Dining Philosophers • Demonstrates many of the problems with concurrency • Deadlock, livelock, and ironically starvation • Akka to the rescue... use ‘become’ • A simple implementation of an FSM

Dining Hakkers sealed trait DiningHakkerMessage case class Busy(chopstick: ActorRef)    extends DiningHakkerMessage case class Put(hakker: ActorRef)    extends DiningHakkerMessage case class Take(hakker: ActorRef)    extends DiningHakkerMessage case class Taken(chopstick: ActorRef)    extends DiningHakkerMessage object Eat extends DiningHakkerMessage object Think extends DiningHakkerMessage

Dining Hakkers class Hakker(name: String, left: ActorRef, right: ActorRef)    extends Actor {   self.id = name   def thinking: Receive = {     case Eat =>       become(hungry)       left ! Take(self)       right ! Take(self)   }   def hungry: Receive = {     case Taken(`left`) =>       become(waiting_for(right,left))     case Taken(`right`) =>       become(waiting_for(left,right))     case Busy(chopstick) =>       become(denied_a_chopstick)   } ...

Top Secret Project • Whisperings of a top secret mission critical project • What if we could ﬁgure out how to brew the perfect beer ? • Use a genetic algorithm to evolve the perfect recipe ? • use Akka for parallel computation ?

Akka Kernel

Start Kernel java ‐jar akka‐1.0‐SNAPSHOT.jar    ‐Dakka.config=<path>/akka.conf

How to run it? Deploy as dependency JAR in WEB-INF/lib etc. Run as stand-alone microkernel OSGi-enabled; drop in any OSGi container (Spring DM server, Karaf etc.)

...and much much more PubSub REST Security FSM Comet Web OSGi Guice

Learn more http://akkasource.org

Akka london scala_user_group

by Skills Matter

Accessibility

Upload Details

Usage Rights

2 Embeds 627

Statistics

Akka london scala_user_group Presentation Transcript

http://skillsmatter.com	626
https://skillsmatter.com	1