Actors Origins Hewitt, early 1970s (1973 paper) Around the same - - PowerPoint PPT Presentation

Actors for Reactive Programming

Actors

Origins

◮ Hewitt, early 1970s (1973 paper) ◮ Around the same time as Smalltalk ◮ Concurrency plus Scheme ◮ Agha, early 1980s (1986 book) ◮ Erlang (Ericsson), 1990s ◮ Akka, 2010s

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 46

Actors for Reactive Programming

Actors: Way of Thinking

◮ Key idea: support for autonomy

◮ Designed for concurrency ◮ Equally good for distribution

◮ Shared nothing

◮ Style of thinking ◮ Architecture: no longer a single locus of control and storage ◮ Programming: reacting to events propagated via messages ◮ Eschew states, visibility of internal information, synchronization

primitives (locks)

◮ Forget threads as a programming abstraction—threads may implicitly

do the work but not to program them

◮ Messaging and no shared memory

◮ Resource management

◮ Start additional actors as needed for work and resources available ◮ Stop actors when not needed ◮ Migrate actors when needed, taking advantage of a universal actor

reference

◮ Handle exceptions through monitoring and supervision Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 47

Actors for Reactive Programming

Actor Basics

◮ An actor

◮ Encapsulates local state (memory)—hence, the state may not be

directly accessed from outside an actor

◮ Encapsulates a thread ◮ Mailbox (incoming) ◮ Processed in order of arrival, though could be reordered (e.g.,

PriorityMailbox)

◮ ActorRef: globally unique ID (serializable) ◮

◮ To create an actor class in Akka,

◮ Extend appropriate abstract class (or, in Scala, trait) ◮ Define a receive method ◮ Define corresponding Props configuration class Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 48

HelloAkkaJava.java (Messages)

p u b l i c c l a s s HelloAkkaJava { //MPS: The f i r s t message i s Greet ; i t has no parameters ; i t s // expected

• utcome

i s to send a g r e e t i n g p u b l i c s t a t i c c l a s s Greet implements S e r i a l i z a b l e {} //MPS: The second message i s WhoToGreet ; i t has

• ne

parameter , // the t a r g e t

• f

the g r e e t i n g ; i t s expected

• utcome

i s f o r // the r e c i p i e n t to change the t a r g e t p u b l i c s t a t i c c l a s s WhoToGreet implements S e r i a l i z a b l e { p u b l i c f i n a l S t r i n g who ; p u b l i c WhoToGreet ( S t r i n g who) { t h i s . who = who ; } } //MPS: The t h i r d message i s G r e e t i n g ; i t has

• ne

parameter , the // g r e e t i n g message ; i t i s a message to be sent p u b l i c s t a t i c c l a s s G r e e t i n g implements S e r i a l i z a b l e { p u b l i c f i n a l S t r i n g message ; p u b l i c G r e e t i n g ( S t r i n g message ) { t h i s . message = message ; } }

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 49

HelloAkkaJava.java (Actor)

p u b l i c s t a t i c c l a s s G r e e t e r extends AbstractActor { S t r i n g g r e e t i n g = ””; // i n t e r n a l s t a t e

• f

the a c t o r @Override //MPS: Mapping

• f

messages to b e h a v i o r s . This s n i p p e t // handles the two incoming messages ; i t doesn ’ t mention // the

• utgoing

message ( G r e e t i n g ) p u b l i c Receive c r e a t e R e c e i v e ( ) { r e t u r n r e c e i v e B u i l d e r ( ) . match ( WhoToGreet . c l a s s , t h i s : : onWhoToGreet ) . match ( Greet . c l a s s , t h i s : : onGreet ) . b u i l d () ; } // MPS: Update i n t e r n a l s t a t e

• n

r e c e i v i n g a WhoToGreet message p r i v a t e void

• nWhoToGreet ( WhoToGreet whoToGreet )

{ g r e e t i n g = ” h e l l o , ” + whoToGreet . who ; } // MPS: Send g r e e t i n g message

• n

r e c e i v i n g a Greet message p r i v a t e void

• nGreet ( Greet

g r e e t ) { // Send the c u r r e n t g r e e t i n g back to the sender getSender () . t e l l ( new G r e e t i n g ( g r e e t i n g ) , g e t S e l f () ) ; } }

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 50

HelloAkkaJava.java (Main 1)

p u b l i c s t a t i c void main ( S t r i n g [ ] args ) { t r y { // Create the helloAkka a c t o r system and the g r e e t e r a c t o r f i n a l ActorSystem system = ActorSystem . c r e a t e (” helloAkka ”) ; f i n a l ActorRef g r e e t e r = system . actorOf ( Props . c r e a t e ( G r e e t e r . c l a s s ) , ” g r e e t e r ”) ; // MPS: The inbox ( apparent misnomer ) f u n c t i o n s as an a c t o r to // communicate with a c t o r s ; s o r t

• f

a ”main” f o r a c t o r s to use // as a p l a c e f o r send and r e c e i v e f i n a l Inbox inbox = Inbox . c r e a t e ( system ) ; // T e l l the g r e e t e r to change i t s ’ g r e e t i n g ’ message g r e e t e r . t e l l ( new WhoToGreet (” akka ”) , ActorRef . noSender ( ) ) ; // Ask f o r the c u r r e n t g r e e t i n g ; r e p l y to go to inbox inbox . send ( g r e e t e r , new Greet () ) ; // Wait 5 seconds f o r the r e p l y with the ’ g r e e t i n g ’ message f i n a l G r e e t i n g g r e e t i n g 1 = ( G r e e t i n g ) inbox . r e c e i v e ( Duration . c r e a t e (5 , TimeUnit .SECONDS) ) ; System . out . p r i n t l n (” G r e e t i n g

• ne :

” + g r e e t i n g 1 . message ) ;

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 51

HelloAkkaJava.java (Main 2)

// I n i t i a l l y a f t e r seconds , send a Greet message e v e r y second to the g r e e t e r ; Spoof sender as G r e e t P r i n t e r ( new Actor below ) f i n a l ActorRef g r e e t P r i n t e r = system . actorOf ( Props . c r e a t e ( G r e e t P r i n t e r . c l a s s ) ) ; system . s c h e d u l e r ( ) . s c h e d u l e ( Duration . Zero ( ) , Duration . c r e a t e (1 , TimeUnit .SECONDS) , g r e e t e r , new Greet ( ) , system . d i s p a t c h e r () , g r e e t P r i n t e r ) ; } catch ( TimeoutException ex ) { System . out . p r i n t l n (” Got a timeout w a i t i n g f o r r e p l y from an a c t o r ”) ; ex . p r i n t S t a c k T r a c e ( ) ; } } p u b l i c s t a t i c c l a s s G r e e t P r i n t e r extends AbstractActor { @Override p u b l i c Receive c r e a t e R e c e i v e ( ) { r e t u r n r e c e i v e B u i l d e r ( ) . match ( G r e e t i n g . c l a s s , ( g r e e t i n g ) − > System . out . p r i n t l n ( g r e e t i n g . message ) ) . b u i l d () ; } } }

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 52

Actors for Reactive Programming

The Receive Method

◮

◮ A reaction rule for each type of message to be handled ◮ In Akka, the set of rules must be exhaustive in that all other messages

will publish an UnhandledMessage to the ActorSystem’s EventStream

◮ Best practice is to include a default rule (using matchAny in Java)

for unexpected messages

◮ Good practice to

◮ Separately describe the allowed message types, e.g., as static classes in

Java

◮ Write each message’s handler as a separate little method

◮ An actor’s receive method

◮ A (partial) function object stored within the actor

◮ Hot swapping the receive: Avoid unless essential

◮ Changed through context.become method ◮ Alternative: push new behavior and use unbecome to post Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 53

Actors for Reactive Programming

Messages

◮ Immutable objects

◮ Not enforced by Java, so beware

◮ No delivery guarantees, pairwise FIFO

◮ May be lost ◮ May be duplicated ◮ Option to ensure at least once delivery

◮ Pairwise FIFO

◮ If ◮ An actor A sends two messages to actor B and ◮ Both messages arrive ◮ Then ◮ They arrive in order

◮ Messages to same recipient from distinct originating actors are

unrelated

◮ May be arbitrarily interleaved

◮ If your application requires some assumptions of delivery

◮ Verify them yourself: use acknowledgments ◮ Achieve them yourself: use retries Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 54

Actors for Reactive Programming

Messages: Programming

◮ tell

◮ Asynchronous ◮ Send message and return immediately ◮ Preferable to maximize decoupling

◮ ask

◮ Asynchronous ◮ Send message and return a Future what will contain the reply ◮ Greater overhead in maintaining the context than for tell

Timeout t = new Timeout ( Duration . c r e a t e (5 , TimeUnit .SECONDS) ) ; CompletableFuture <Object> f u t u r e 2 = ask ( actorB , ” another r e q u e s t ” , t ) . toCompletableFuture () ; ◮ The CompletableFuture class supports joining futures, piping, and

so on

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 55

Actors for Reactive Programming

ActorSystem

/ root (and its guardian or supervisor) /user user space (and its guardian or supervisor), called Guardian /system system space (and its guardian or supervisor)

◮ Any actors we create are under /user, although we create actors

through

◮ system.actorOf: children (called “top-level” actors) of /user ◮ context.actorOf: their descendants (all levels)

◮ Every actor has a parent or supervisor in whose scope it is created ◮ Stopping an actor: recursively: children first; then self

◮ getContext().stop(child) ◮ getContext().stop(getSelf()) ◮ PoisonPill message to stop an actor in its tracks after the previously

arrived (enqueued) messages are processed

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 56

Actors for Reactive Programming

Exceptions

◮ Current message

◮ Already removed from mailbox and potentially lost ◮ Unless explicit action to save the message or process it again

◮ Mailbox

◮ Preserved, as remaining after the current message was removed ◮ Available to the restarted actor, if any

◮ Supervision: An exception throwing actor is suspended and control

passed to its supervisor

◮ The supervisor decides the fate of the actor

◮ Resume: back to where it was when the exception occurred ◮ Restart: reset its internal state to initial ◮ Stop: end it

◮ Akka provides a rich set of hooks through which to customize

behavior

◮ Pre and post of the major events ◮ Start, Stop, Restart ◮ For example, preRestart() Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 57

Actors for Reactive Programming

Exceptions: Supervisor Strategy

◮ No call stack to pass an exception

◮ Traditional idea doesn’t work ◮ Not clear which past or future caller should get the exception

◮ Therefore, pass to supervisor

◮ Can apply its strategy ◮ A couple of strategies are predefined

◮ One for One Strategy

◮ If a child (supervisee) actor produces an exception, deal with that actor

◮ All for One Strategy

◮ If the child actors are performing pieces of the same transaction and

those not throwing an exception may be affected

◮ Predefined (fixed set of) directives on how to deal with a spoiled child

◮ Resume ◮ Stop ◮ Restart ◮ Escalate Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 58

Exception Handling: Throwing

c l a s s MadeUpException (msg : S t r i n g ) extends Exception (msg) {} c l a s s JustBecauseException (msg : S t r i n g ) extends Exception (msg) {} c l a s s S u p e r v i s e e A c t o r ( i d : I n t ) extends Actor with ActorLogging { . . .

• v e r r i d e

def r e c e i v e : Receive = { case S u p e r v i s e e A c t o r . F a i l = > log . i n f o ( s ” $ s e l f f a i l s now , i d e n t i f i e r = $ i d e n t i f i e r ; ActorRef = $ t h i s ”) throw new JustBecauseException ( s ” $ s e l f , i d e n t i f i e r = $ i d e n t i f i e r , upon r e c e i v i n g a F a i l message ”) case S u p e r v i s e e A c t o r . Nudge = > import u t i l . Random i f (Random . nextBoolean ( ) ) throw new MadeUpException ( s ” $ s e l f , i d e n t i f i e r = $ i d e n t i f i e r , random e f f e c t

• n a Nudge message ”)

log . i n f o ( s ” $ s e l f r e c e i v e s nudge from $sender , i d e n t i f i e r = $ i d e n t i f i e r ; ActorRef = $ t h i s ”) } }

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 59

Exception Handling: “Catching”

c l a s s S u p e r v i s o r A c t o r extends Actor with ActorLogging { . . . v a l c h i l d = context . actorOf ( . . . )

• v e r r i d e

def r e c e i v e : Receive = { case S u p e r v i s o r A c t o r . F a i l C h i l d = > c h i l d ! S u p e r v i s e e A c t o r . F a i l case S u p e r v i s o r A c t o r . NudgeChild = > c h i l d ! S u p e r v i s e e A c t o r . Nudge }

• v e r r i d e

v a l s u p e r v i s o r S t r a t e g y = OneForOneStrategy ( maxNrOfRetries = 1 , withinTimeRange = 5 second ) { case : A r i t h m e t i c E x c e p t i o n = > Resume case : N u l l P o i n t e r E x c e p t i o n = > R e s t a r t case : I l l e g a l A r g u m e n t E x c e p t i o n = > Stop case : IOException = > Stop case x : JustBecauseException = > { log . e r r o r ( s ” JustBecauseException

• ccurred

f o r the most

• utrageous

reason ;\ n< < <$x>>>\n R e s t a r t i n g ”) R e s t a r t } case : MadeUpException = > { log . e r r o r ( s ”MadeUpException

• ccurred ;\ n Resuming ”)

Resume } case : Exception = > E s c a l a t e }

Actors for Reactive Programming

End-to-End Principle

Popularized by Jerome Saltzer, David Reed, and David Clark

◮ Originally formulated for computer network protocols

◮ Usual examples pertain to error checking and performance ◮ A similar case could be made for encryption

◮ Applies to (distributed) computing more generally

◮ Any functionality that reflects application meaning must be verified at

the end points

◮ Such functionality ◮ Does not need to be provided in the interior of the network, because it

would need to be repeated at the end points

◮ Functionality that is not needed for a layer should not be provided in

that layer because it is

◮ Either superfluous—hence wastes resources ◮ Or is replicated—hence wastes resources

◮ In the case of actors

◮ Ignoring message reliability and ordering is wise ◮ But why not also discard pairwise FIFO Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 61

Actors for Reactive Programming

Actors and Protocols

Protocols to be introduced later

◮ Actors

◮ Separate business logic from infrastructure

◮ Protocols

◮ Separate reasoning from coordination

◮ Concordance: Protocols are geared for coordination of actor-like

computational entities

◮ Asynchronous (nonblocking) messaging ◮ Shared nothing representation of local state

◮ Complementarity

◮ Actors assume pairwise FIFO ◮ Actors lack a model of multiparty interactions ◮ Actors lack an explicit model of causality for messages ◮ Actors don’t provide an information model for messages ◮ Protocols deal with interactions; actors deal with computations that

can interact

Munindar P. Singh (NCSU) Service-Oriented Computing Fall 2017 62