Actors for Reactive Programming. Actors Origins

Transcription

1 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

2 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

3 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

4 HelloAkkaJava.java (Messages) p u b l i c c l a s s H e l l o A k k a J a v a { //MPS: The f i r s t message i s G r e e t ; i t has no p a r a m e t e r s ; i t s // e x p e c t e d outcome 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 G r e e t implements S e r i a l i z a b l e { //MPS: The second message i s WhoToGreet ; i t has one parameter, // t h e t a r g e t o f t h e g r e e t i n g ; i t s e x p e c t e d outcome i s f o r // t h e r e c i p i e n t to change t h e 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 one parameter, t h e // g r e e t i n g message ; i t i s a message to be s e n t 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

5 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 e x t e n d s A b s t r a c t A c t o r { 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 o f t h e a c t o O v e r r i d e //MPS: Mapping o f messages to b e h a v i o r s. This s n i p p e t // h a n d l e s t h e two incoming messages ; i t doesn t mention // t h e o u t g o i n g message ( G r e e t i n g ) p u b l i c R e c e i v e 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 ( G r e e t. 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 on r e c e i v i n g a WhoToGreet message p r i v a t e v o i d onwhotogreet ( 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 on r e c e i v i n g a G r e e t message p r i v a t e v o i d ongreet ( G r e e t g r e e t ) { // Send t h e c u r r e n t g r e e t i n g back to t h e s e n d e r g e t S e n d e r ( ). 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

6 HelloAkkaJava.java (Main 1) p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) { t r y { // C r e a t e t h e h e l l o A k k a a c t o r system and t h e 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 ( h e l l o A k k a ) ; f i n a l A c t o r R e f g r e e t e r = system. a c t o r O f ( 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 i n b o x ( a p p a r e n t misnomer ) f u n c t i o n s as an a c t o r to // communicate w i t h a c t o r s ; s o r t o 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 I n b o x i n b o x = I n b o x. c r e a t e ( system ) ; // T e l l t h e 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 ), A c t o r R e f. nosender ( ) ) ; // Ask f o r t h e c u r r e n t g r e e t i n g ; r e p l y to go to i n b o x i n b o x. send ( g r e e t e r, new G r e e t ( ) ) ; // Wait 5 s e c o n d s f o r t h e r e p l y w i t h t h e 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 ) i n b o x. r e c e i v e ( D u r a t i o n. 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 one : + g r e e t i n g 1. message ) ; Munindar P. Singh (NCSU) Service-Oriented Computing Fall

7 HelloAkkaJava.java (Main 2) // I n i t i a l l y a f t e r 0 seconds, send a G r e e t message e v e r y second to t h e g r e e t e r ; Spoof s e n d e r as G r e e t P r i n t e r ( new Actor below ) f i n a l A c t o r R e f g r e e t P r i n t e r = system. a c t o r O f ( 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 ( D u r a t i o n. Zero ( ), D u r a t i o n. c r e a t e ( 1, TimeUnit. SECONDS), g r e e t e r, new G r e e t ( ), system. d i s p a t c h e r ( ), g r e e t P r i n t e r ) ; c a t c h ( TimeoutException ex ) { System. out. p r i n t l n ( Got a t i m e o u t 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 e x t e n d s A b s t r a c t A c t o r O v e r r i d e p u b l i c R e c e i v e 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

8 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

9 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

10 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 ( D u r a t i o n. c r e a t e ( 5, TimeUnit. SECONDS) ) ; C o m p l e t a b l e F u t u r e <Object> f u t u r e 2 = ask ( actorb, a n o t h e r r e q u e s t, t ). t o C o m p l e t a b l e F u t u r e ( ) ; The CompletableFuture class supports joining futures, piping, and so on Munindar P. Singh (NCSU) Service-Oriented Computing Fall

11 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

12 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

13 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

14 Exception Handling: Throwing c l a s s MadeUpException ( msg : S t r i n g ) e x t e n d s E x c e p t i o n ( msg ) { c l a s s J u s t B e c a u s e E x c e p t i o n ( msg : S t r i n g ) e x t e n d s E x c e p t i o n ( 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 ) e x t e n d s Actor w i t h A c t o r L o g g i n g {... o v e r r i d e d e f r e c e i v e : R e c e i v e = { c a s e S u p e r v i s e e A c t o r. F a i l => l o g. 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 ; A c t o r R e f = $ t h i s ) throw new J u s t B e c a u s e E x c e p t i o n ( 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 ) c a s e S u p e r v i s e e A c t o r. Nudge => i m p o r t u t i l. Random i f ( Random. n e x t B o o l e a n ( ) ) 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 on a Nudge message ) l o g. 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 ; A c t o r R e f = $ t h i s ) Munindar P. Singh (NCSU) Service-Oriented Computing Fall

15 Exception Handling: Catching c l a s s S u p e r v i s o r A c t o r e x t e n d s Actor w i t h A c t o r L o g g i n g {... v a l c h i l d = c o n t e x t. a c t o r O f (... ) o v e r r i d e d e f r e c e i v e : R e c e i v e = { c a s e 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 c a s e 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 o 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 ) { c a s e : A r i t h m e t i c E x c e p t i o n => Resume c a s e : 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 c a s e : 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 c a s e : I O E x c e p t i o n => Stop c a s e x : J u s t B e c a u s e E x c e p t i o n => { l o g. e r r o r ( s J u s t B e c a u s e E x c e p t i o n o c c u r r e d f o r t h e most o u t r a g e o u s r e a s o n ; \ n<<<$x>>>\n R e s t a r t i n g ) R e s t a r t c a s e : MadeUpException => { l o g. e r r o r ( s MadeUpException o c c u r r e d ; \ n Resuming ) Resume c a s e : E x c e p t i o n => E s c a l a t e

16 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

17 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