Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Error Handling in Reactive Systems

Error handling is critical for reactive systems, as expressed by the "resilient" trait. This talk examines strengths and weaknesses of existing approaches. I also consider preventing errors in the first place.

  • Sé el primero en comentar

Error Handling in Reactive Systems

  1. 1. Error Handling in Reactive Systems Dean Wampler ©Typesafe 2014 – All Rights Reserved 1 Wednesday, November 19, 14 Photos from Jantar Mantar (“instrument”, “calcula8on”), the astronomical observatory built in Jaipur, India, by Sawai Jai Singh, a Rajput King, in the 1720s-­‐30s. He built four others around India. This is the largest and best preserved. All photos are copyright (C) 2012-­‐2014, Dean Wampler. All Rights Reserved.
  2. 2. dean.wampler@typesafe.com polyglotprogramming.com/talks @deanwampler ©Typesafe 2014 – All Rights Reserved 2 Wednesday, November 19, 14
  3. 3. Typesafe Reactive Big Data ©Typesafe 2014 – All Rights Reserved 3 typesafe.com/reactive-big-data Wednesday, November 19, 14 This is my role. We’re just geTng started, but talk to me if you’re interested in what we’re doing.
  4. 4. Responsive Elastic Resilient Message Driven ©Typesafe 2014 – All Rights Reserved 4 Wednesday, November 19, 14
  5. 5. ©Typesafe 2014 – All Rights Reserved 5 Responsive Resilient Message Driven Failures are first class? Wednesday, November 19, 14 Truly resilient systems must make failures first class ci8zens, in some sense of the word, because they are inevitable when the systems are big enough and run long enough.
  6. 6. ©Typesafe 2014 – All Rights Reserved 6 Wednesday, November 19, 14 I’ve structured this talk around some points made in Debasish’s new book, which has lots of interes8ng prac8cal ideas for combining func8onal programming and reac8ve approaches with classic Domain-­‐ Driven Design by Eric Evans.
  7. 7. #1 Failure-handling mixed with domain logic. ©Typesafe 2014 – All Rights Reserved 7 Wednesday, November 19, 14 This is how we’ve always done it, right?
  8. 8. Best for narrowly-scoped errors. –Parsing user input. –Transient stream interruption. –Failover from one stream to a “backup”. ©Typesafe 2014 – All Rights Reserved 8 Wednesday, November 19, 14
  9. 9. Limited to per stream handling. Hard to implement a larger strategy. ©Typesafe 2014 – All Rights Reserved 9 Wednesday, November 19, 14
  10. 10. Communicating Sequential Processes Message passing via channels ©Typesafe 2014 – All Rights Reserved 10 Wednesday, November 19, 14 See h^p://en.wikipedia.org/wiki/Communica8ng_sequen8al_processes h^p://clojure.com/blog/2013/06/28/clojure-­‐core-­‐async-­‐channels.html h^p://blog.drewolson.org/blog/2013/07/04/clojure-­‐core-­‐dot-­‐async-­‐and-­‐go-­‐a-­‐code-­‐comparison/ and other references in the “bonus” slides at the end of the deck. I also have some slides that describe the core primi8ves of CSP that I won’t have 8me to cover.
  11. 11. “Don’t communicate by sharing memory, share memory by communicating” ©Typesafe 2014 – All Rights Reserved 11 -- Rob Pike Wednesday, November 19, 14 h^p://www.youtube.com/watch?v=f6kdp27TYZs&feature=youtu.be From a talk Pike did at Google I/O 2012.
  12. 12. CSP-inspired Go & Clojure’s core.async ©Typesafe 2014 – All Rights Reserved 12 Wednesday, November 19, 14
  13. 13. Get Value ©Typesafe 2014 – All Rights Reserved 13 Put Value Blocking Channel Wednesday, November 19, 14 Simplest channel, a blocking, 1-­‐element “connector” used to share values, one at a 8me between a source and a wai8ng sync. The put opera8on blocks if there is no sync wai8ng on the other end. The channel can be typed (Go lang). Doesn’t prevent the usual problems if mutable state is passed over a channel!
  14. 14. Get Value Put Value Blocking Channel •Block on put if no one to get. •Channel can be typed. •Avoid passing mutable state! ©Typesafe 2014 – All Rights Reserved 14 Wednesday, November 19, 14 Simplest channel, a blocking, 1-­‐element “connector” used to share values, one at a 8me between a source and a wai8ng sync. The put opera8on blocks if there is no sync wai8ng on the other end. The channel can be typed (Go lang). Doesn’t prevent the usual problems if mutable state is passed over a channel!
  15. 15. Get Value ©Typesafe 2014 – All Rights Reserved 15 Put Value Bounded, Nonblocking Channel N = 3 Wednesday, November 19, 14 A non-­‐blocking queue, but bounded in size. Normally, N wouldn’t be this small. You DON’T want it to be infinite either, because eventually you’ll fill it and run out of memory!
  16. 16. Get Value Put Value Bounded, Nonblocking Channel N = 3 •When full: •Block on put. •Drop newest (i.e., put value). •Drop oldest (“sliding” window). ©Typesafe 2014 – All Rights Reserved 16 Wednesday, November 19, 14 What should you do when it’s full?
  17. 17. Go Block Go Block Get Value ©Typesafe 2014 – All Rights Reserved 17 Put Value Bounded, Nonblocking Channel N = 3 Wednesday, November 19, 14 So far, we haven’t supported any actual concurrency. I’m using “Go Blocks” here to represent explicit threads in Clojure, when running on the JVM and you’re willing to dedicate a thread to the sequence of code, or core async “go blocks”, which provide thread-­‐like async behavior, but share real threads. This is the only op8on for clojure.js, since you only have one thread period. Similarly for Go, “go blocks” would be “go rou8nes”. In all cases, they are analogous to Java/Scala futures.
  18. 18. Go Block Go Block Get Value Put Value Bounded, Nonblocking Channel N = 3 •Core Async: Go Blocks, Threads. •Go: Go Routines. •Analogous to futures. ©Typesafe 2014 – All Rights Reserved 18 Wednesday, November 19, 14 So far, we haven’t supported any actual concurrency. I’m using “Go Blocks” here to represent explicit threads in Clojure, when running on the JVM and you’re willing to dedicate a thread to the sequence of code, or core async “go blocks”, which provide thread-­‐like async behavior, but share real threads. This is the only op8on for clojure.js, since you only have one thread period. Similarly for Go, “go blocks” would be “go rou8nes”. In all cases, they are analogous to Java/Scala futures.
  19. 19. Go Block Put Value Go Block ©Typesafe 2014 – All Rights Reserved 19 Go Block Put Value Get Value Bounded, Nonblocking Channel N = 3 Wednesday, November 19, 14 You can “select’ on several channels, analogous to socket select. I.e., read from the next channel with a value. In go, there is a “select” construct for this. In core async, there are the “alt!” (blocking) and “alt!!” (nonblocking) func8ons. Fan out is also possible.
  20. 20. Bounded, Nonblocking Channel Go Block Put Value Go Block Go Block Put Value Get Value N = 3 •Blocking or nonblocking. •Like socket select. ©Typesafe 2014 – All Rights Reserved 20 Wednesday, November 19, 14 You can “select’ on several channels, analogous to socket select. I.e., read from the next channel with a value. In go, there is a “select” construct for this. In core async, there are the “alt!” (blocking) and “alt!!” (nonblocking) func8ons. Fan out is also possible.
  21. 21. At this point, neither Go nor Core Async have implemented distributed channels. However, channels are often used to implement end points for network and file I/O, etc. ©Typesafe 2014 – All Rights Reserved 21 Wednesday, November 19, 14 In other words, no one has extended the channel formalism outside process boundaries (compare to Actors...), but channels are ooen used to handle blocking I/O, etc.
  22. 22. Failure Handling in Core Async ©Typesafe 2014 – All Rights Reserved 22 Wednesday, November 19, 14 The situa8on is broadly similar for Go. Some items here are adapted from a private conversa8on with Alex Miller (@puredanger).
  23. 23. Channel construction takes an optional exception function. •The exception is passed to the function. •If it returns non-nil, that value is put on the channel. ©Typesafe 2014 – All Rights Reserved 23 Wednesday, November 19, 14 Using this feature is almost always what you should do, because you have almost no other good op8ons.
  24. 24. Which call stack? •Processing logic can span several threads! •A general problem for concurrency implemented using multithreading. ©Typesafe 2014 – All Rights Reserved 24 Wednesday, November 19, 14 Since it’s not a distributed system, core async only needs to handle errors in a single process, but you s8ll can have mul8ple threads.
  25. 25. Go Block Get Value Propagate exceptions back through the channel. ©Typesafe 2014 – All Rights Reserved 25 Go Block Put Value Time Handle Exception Exception Wednesday, November 19, 14 One possible scheme is to push excep8ons back through the channel and let the ini8alizing go block decide what to do. It might rethrow the excep8on.
  26. 26. Go Block Handle Exception Go Block Get Value Go Block Put Value Time Error Channel Exception Propagate exceptions to a special error channel. ©Typesafe 2014 – All Rights Reserved 26 Wednesday, November 19, 14 Another possible scheme is to send excep8ons down a specialized error channel.
  27. 27. Deadlock are possible unless timeouts are used. ©Typesafe 2014 – All Rights Reserved 27 Put Value Blocking Channel ??? Timeout Wednesday, November 19, 14
  28. 28. Reactive Extensions ©Typesafe 2014 – All Rights Reserved 28 Wednesday, November 19, 14 I’ll look at C# examples, but all the Rx language implementa8ons work similarly.
  29. 29. Observable LINQ filter map … ©Typesafe 2014 – All Rights Reserved 29 Async Event Stream Schedulers Wednesday, November 19, 14
  30. 30. Uses classic exception handling patterns, with extensions. ©Typesafe 2014 – All Rights Reserved 30 Wednesday, November 19, 14
  31. 31. OnError notification caught with a Catch method. •Switch to a second stream. val stream = new Subject<MyType>(); val observer = stream.Catch(otherStream); ... stream.OnNext(item1); ... stream.OnError(new Exception(“error”)); // continue with otherStream. ©Typesafe 2014 – All Rights Reserved 31 Wednesday, November 19, 14 Adapted from h^p://www.introtorx.com/content/v1.0.10621.0/11_AdvancedErrorHandling.html
  32. 32. Variant for catching a specific exception, with a function to construct a new stream. val stream = new Subject<MyType>(); val observer = stream.Catch<MyType,MyEx>( ex => /* create new MyType stream */); ... stream.OnNext(item1); ... stream.OnError(new MyEx(“error”)); // continue with generated stream. ©Typesafe 2014 – All Rights Reserved 32 Wednesday, November 19, 14 Adapted from h^p://www.introtorx.com/content/v1.0.10621.0/11_AdvancedErrorHandling.html
  33. 33. There is also a Finally method. Analogous to try {...} finally {...} clauses. ©Typesafe 2014 – All Rights Reserved 33 Wednesday, November 19, 14 Adapted from h^p://www.introtorx.com/content/v1.0.10621.0/11_AdvancedErrorHandling.html
  34. 34. OnErrorResumeNext: Swallows exception, continues with alternative stream(s). public static IObservable<TSource> OnErrorResumeNext<TSource>( this IObservable<TSource> first, IObservable<TSource> second) {...} public static IObservable<TSource> OnErrorResumeNext<TSource>( params IObservable<TSource>[] sources) {...} ... ©Typesafe 2014 – All Rights Reserved 34 Wednesday, November 19, 14 Adapted from h^p://www.introtorx.com/content/v1.0.10621.0/11_AdvancedErrorHandling.html 2 of the 3 variants.
  35. 35. Retry: Are some exceptions expected, e.g., I/O “hiccups”. Keeps trying. Optional max retries. public static void RetrySample<T>( IObservable<T> source) { source.Retry(4) // retry up to 4 times. .Subscribe(t => Console.WriteLine(t)); Console.ReadKey(); } ©Typesafe 2014 – All Rights Reserved 35 Wednesday, November 19, 14 Adapted from h^p://www.introtorx.com/content/v1.0.10621.0/11_AdvancedErrorHandling.html
  36. 36. CSP & Rx: Failure management is per-stream, mixed with domain logic. ©Typesafe 2014 – All Rights Reserved 36 Wednesday, November 19, 14 What CSP-­‐derived and Rx concurrency systems do, they do well, but we need a larger strategy for reac8ve resiliency at scale. Before we consider such strategies, let’s discuss another technique.
  37. 37. #2 Prevent common problems. ©Typesafe 2014 – All Rights Reserved 37 Wednesday, November 19, 14 This is how we’ve always done it, right?
  38. 38. Reactive Streams ©Typesafe 2014 – All Rights Reserved 38 Wednesday, November 19, 14 Reac8ve Streams extend the capabili8es of CSP channels and Rx by addressing flow control concerns. They
  39. 39. Reactive Streams ©Typesafe 2014 – All Rights Reserved 39 Event Event Event Event Event Event Event/Data Stream Consumer feedback Consumer bounded queue feedback feedback Wednesday, November 19, 14
  40. 40. Reactive Streams Streams (data flows) are a natural model for many distributed problems, i.e., one-way CSP channels at scale. ©Typesafe 2014 – All Rights Reserved 40 Event Event Event Event Event Event Event/Data Stream Consumer feedback Consumer bounded queue feedback feedback Wednesday, November 19, 14
  41. 41. #3 Leverage types to prevent errors. ©Typesafe 2014 – All Rights Reserved 41 Wednesday, November 19, 14 This is how we’ve always done it, right?
  42. 42. Express what’s really happening with types. ©Typesafe 2014 – All Rights Reserved 42 Wednesday, November 19, 14 First, let’s at least be honest with the reader about what’s actually happening in blocks of code.
  43. 43. When code raises exceptions: case class Order( id: Long, cost: Money, items: Seq[(Int,SKU)]) object Order { def parse(string: String): Try[Order] = Try { val array = string.split("t") // raise exceptions for bad records new Order(...) } } ©Typesafe 2014 – All Rights Reserved 43 Wednesday, November 19, 14 Idioma8c Scala for “defensive” parsing of incoming data as strings. Wrap the parsing and construc8on logic in a Try {...}. Note the capital T; this will construct a Try instance, either a subclass Success, if everything works, or a Failure, if an excep8on is thrown. See the github repo for this presenta8on for a complete example: h^ps://github.com/deanwampler/Presenta8ons
  44. 44. Latency? Use Futures • Or equivalents, like go blocks. case class Account( id: Long, orderIds: Seq[Long]) def getAccount(id: Long): Future[Account] = Future { /* Web service, DB query, etc... */ } def getOrders(ids: Seq[Long]): Future[Seq[Order]] = Future { /* Web service, DB query, etc... */ } ... ©Typesafe 2014 – All Rights Reserved 44 Wednesday, November 19, 14 See the github repo for this presenta8on for a complete example: h^ps://github.com/deanwampler/ Presenta8ons
  45. 45. Latency? Use Futures • Or equivalents, like go blocks. ... def ordersForAccount(accountId: Long): Future[Seq[Order]] = for { account <- getAccount(accountId) orders <- getOrders(account.orderIds) } yield orders ©Typesafe 2014 – All Rights Reserved 45 Wednesday, November 19, 14 Futures can be sequenced “monadically”, so our code has a nice synchronous feel to it, but we can exploit async. execu8on. See the github repo for this presenta8on for a complete example: h^ps://github.com/deanwampler/Presenta8ons
  46. 46. Latency? Use Futures • Or equivalents, like go blocks. val accountId = ... val ordersFuture = ordersForAccount(accountId) ordersFuture.onSuccess { case orders => println(s"#$accountId: $orders") } ordersFuture.onFailure { case exception => println(s"#$accountId: " + "Failed to process orders: $exception") } ©Typesafe 2014 – All Rights Reserved 46 Wednesday, November 19, 14 See the github repo for this presenta8on for a complete example: h^ps://github.com/deanwampler/ Presenta8ons
  47. 47. Use types to enforce correctness. ©Typesafe 2014 – All Rights Reserved 47 Wednesday, November 19, 14 First, let’s at least be honest with the reader about what’s actually happening in blocks of code.
  48. 48. Functional Reactive Programming ©Typesafe 2014 – All Rights Reserved 48 Wednesday, November 19, 14 On the subject of type safety, let’s briefly discuss FRP. It was invented in the Haskell community, where there’s a strong commitment to type safety as a tool for correctness.
  49. 49. Represent evolving state by time-varying values. ©Typesafe 2014 – All Rights Reserved 49 Reactor.flow { reactor => val path = new Path( (reactor.await(mouseDown)).position) reactor.loopUntil(mouseUp) { val m = reactor.awaitNext(mouseMove) path.lineTo(m.position) draw(path) } path.close() draw(path) } From Deprecating the Observer Pattern with Scala.React. Wednesday, November 19, 14 Draw a line on a UI from the ini8al point to the current mouse point, as the mouse moves. This API is from a research paper. I could have used Elm (FRP for JavaScript) or one of the Haskell FRP APIs (where FRP was pioneered), but this DSL is reasonably easy to understand. Here, we have a stream of data points, so it resembles Rx in its concepts.
  50. 50. Can you declaratively prevent errors? ©Typesafe 2014 – All Rights Reserved 50 Sculthorpe and Nilsson, Safe functional reactive programming through dependent types Wednesday, November 19, 14 True to its Haskell routes, FRP tries to use the type system to explicitly h^p://dl.acm.org/cita8on.cfm?doid=1596550.1596558
  51. 51. #4 Manage errors separately. ©Typesafe 2014 – All Rights Reserved 51 Wednesday, November 19, 14 This is how we’ve always done it, right?
  52. 52. Actor Model ©Typesafe 2014 – All Rights Reserved 52 Wednesday, November 19, 14
  53. 53. Actor ActorRef Actor Send a message Superficially similar to channels. ©Typesafe 2014 – All Rights Reserved 53 Mail box (message queue) Handle a message Wednesday, November 19, 14 This is how they look in Akka, where there is a layer of indirec8on, the ActorRef, between actors. This helps with the drawback that actors know each other’s iden88es, but mostly it’s there to make the system more resilient, where a failed actor can be restarted while keeping the same ActorRef that other actors hold on to.
  54. 54. In response to a message, an Actor ActorRef Actor Actor can: •Send 0-n msgs to other actors. •Mail box (Create message 0-n new actors. queue) •Change its behavior for responding to the next message. Send a message Handle a message ©Typesafe 2014 – All Rights Reserved 54 Wednesday, November 19, 14
  55. 55. Messages are: •Handled asynchronously. •Usually untyped. Actor ActorRef Actor Mail box (message queue) Send a message Handle a message ©Typesafe 2014 – All Rights Reserved 55 Wednesday, November 19, 14
  56. 56. CSP and Actors are dual ©Typesafe 2014 – All Rights Reserved 56 Wednesday, November 19, 14
  57. 57. CSP Processes are anonymous Bounded, Nonblocking Channel ©Typesafe 2014 – All Rights Reserved 57 ... while actors have identities. Go Block Go Block Put Get Value Value N = 3 Wednesday, November 19, 14
  58. 58. CSP messaging is synchronous Bounded, Nonblocking Channel ©Typesafe 2014 – All Rights Reserved 58 A sender and receiver must rendezvous, while actor messaging is asynchronous. Go Block Go Block Put Get Value Value N = 3 Wednesday, November 19, 14 In actors, the receiver doesn’t even need to be ready to receive messages yet.
  59. 59. ... but CSP and Actors can implement each other ©Typesafe 2014 – All Rights Reserved 59 Wednesday, November 19, 14
  60. 60. An actor mailbox looks a lot like a channel. Go Block Go Block Put Value Send a message Actor Actor ©Typesafe 2014 – All Rights Reserved 60 Bounded, Nonblocking Channel Get Value N = 3 ActorRef Mail box (message queue) Handle a message Wednesday, November 19, 14 In actors, the receiver doesn’t even need to be ready to receive messages yet.
  61. 61. CSP Processes are anonymous ©Typesafe 2014 – All Rights Reserved 61 Actor identity can be hidden behind a lookup service. An actor can be used as a channel , i.e., a “message broker”. Wednesday, November 19, 14
  62. 62. CSP Processes are anonymous Conversely, a reference to the channel is often shared between a sender and receiver. ©Typesafe 2014 – All Rights Reserved 62 Wednesday, November 19, 14
  63. 63. CSP messaging is synchronous ©Typesafe 2014 – All Rights Reserved 63 Actor messaging can be synchronous if the sender uses a blocking message send that waits for a response. blocking message Actor Actor Reply Wednesday, November 19, 14 Most actor systems provide a blocking message send primi8ve where the “thread” blocks un8l an answer message is received.
  64. 64. CSP messaging is synchronous Bounded, Nonblocking Channel ©Typesafe 2014 – All Rights Reserved 64 Buffered channels behave asynchronously. Go Block Go Block Put Get Value Value N = 3 Wednesday, November 19, 14 In actors, the receiver doesn’t even need to be ready to receive messages yet.
  65. 65. ©Typesafe 2014 – All Rights Reserved Erlang and Akka 65 Wednesday, November 19, 14
  66. 66. Distributed Actors •Generalize actor identities to URLs. •But distribution adds a number of failure modes... ©Typesafe 2014 – All Rights Reserved 66 Wednesday, November 19, 14 URL vs. URI?? See h^p://danielmiessler.com/study/ url_vs_uri/
  67. 67. Failure-handling in Actor Systems ©Typesafe 2014 – All Rights Reserved 67 Wednesday, November 19, 14
  68. 68. Let it Crash! ©Typesafe 2014 – All Rights Reserved 68 Wednesday, November 19, 14
  69. 69. Erlang introduced supervisors A hierarchy of actors that manage each “worker” actor’s lifecycle. Supervisor 1 Actor 12 Supervisor 11 Actor 111 Actor 112 Actor 13 Actor 131 Actor 132 ©Typesafe 2014 – All Rights Reserved 69 Wednesday, November 19, 14
  70. 70. Erlang introduced supervisors Generalizes nicely to distributed actor systems. Supervisor 1 Actor 12 Supervisor 11 Actor 111 Actor 112 Actor 13 Actor 131 Actor 132 ©Typesafe 2014 – All Rights Reserved 70 Wednesday, November 19, 14
  71. 71. Supervisor 1 Actor 12 Supervisor 11 Actor 111 Actor 112 X Actor 13 Actor 131 Actor 132 ©Typesafe 2014 – All Rights Reserved 71 Wednesday, November 19, 14
  72. 72. Supervisor 1 Actor 12 Actor 111 Actor 112 ©Typesafe 2014 – All Rights Reserved 72 Supervisor 11 Wednesday, November 19, 14
  73. 73. Actor 13 Actor 131 Actor 132 Supervisor 1 Actor 12 Actor 111 Actor 112 ©Typesafe 2014 – All Rights Reserved 73 Supervisor 11 Wednesday, November 19, 14
  74. 74. Advantages •Enables strategic error handling across module boundaries. •Separates normal and error logic. •Failure handling is configurable and pluggable. ©Typesafe 2014 – All Rights Reserved 74 Wednesday, November 19, 14
  75. 75. Criticisms of Actors ©Typesafe 2014 – All Rights Reserved 75 Wednesday, November 19, 14
  76. 76. Rich Hickey ©Typesafe 2014 – All Rights Reserved 76 [Actors] still couple the producer with the consumer. Yes, one can emulate or implement certain kinds of queues with actors, but since any actor mechanism already incorporates a queue, it seems evident that queues are more primitive. ... and channels are oriented towards the flow aspects of a system. Wednesday, November 19, 14 From h^p://clojure.com/blog/2013/06/28/clojure-­‐core-­‐async-­‐ channels.html
  77. 77. Tim Baldridge’s Criticisms ©Typesafe 2014 – All Rights Reserved 77 •Unbounded queues (mailboxes). •Internal mutating state (hidden in function closures). •Must send message to deref state. What if the mailbox is backed up? •Couples a queue, mutating state, and a process. •Effectively “asynchronous OOP”. Wednesday, November 19, 14 From h^ps://github.com/halgari/clojure-­‐conj-­‐2013-­‐core.async-­‐examples/blob/master/src/clojure_conj_talk/core.clj Most of these are based on his toy example, not a produc8on-­‐calibre implementa8on.
  78. 78. ©Typesafe 2014 – All Rights Reserved I’ll add... 78 •Most actor systems are untyped. •Typed channels add that extra bit of type safety. Wednesday, November 19, 14
  79. 79. Answers ©Typesafe 2014 – All Rights Reserved 79 Wednesday, November 19, 14 The fact that Actors and CSP can be used to implement each other suggests that the cri8cisms are less than meets the eye...
  80. 80. Unbounded queues •Bounded queues are available in production-ready Actor implementations. •Reactive Streams with back pressure enable strategic management of flow. ©Typesafe 2014 – All Rights Reserved 80 Wednesday, November 19, 14 In other words, ignore toy examples.
  81. 81. Reactive Streams Akka streams provide a higher-level abstraction on top of Actors with better type safety (effectively, typed channels) and operational semantics. ©Typesafe 2014 – All Rights Reserved 81 Event Event Event Event Event Event Event/Data Stream Consumer feedback Consumer bounded queue feedback feedback Wednesday, November 19, 14
  82. 82. Internal mutating state ©Typesafe 2014 – All Rights Reserved 82 •Actually an advantage. •Encapsulation of mutating state within an Actor is a systematic approach to large-scale, reliable management of state evolution. •“Asynchronous OOP” is a fine strategy when it fits your problem. Wednesday, November 19, 14
  83. 83. Must send message to get state ©Typesafe 2014 – All Rights Reserved 83 •Also an advantage. •Protocol for coordinating reads and writes. Wednesday, November 19, 14
  84. 84. Couples a queue, mutable state, and a process ©Typesafe 2014 – All Rights Reserved 84 •Production systems provide as much decoupling as you need. Wednesday, November 19, 14
  85. 85. Actors are untyped •While there have been typed actor implementations, actors are analogous to OS processes: •Clear abstraction boundaries. •But careful handling of inputs required. ©Typesafe 2014 – All Rights Reserved 85 Wednesday, November 19, 14
  86. 86. Actors are untyped •... but actually, Akka is adding typed ActorRefs. ©Typesafe 2014 – All Rights Reserved 86 Wednesday, November 19, 14
  87. 87. How should we handle failures? ©Typesafe 2014 – All Rights Reserved 87 Wednesday, November 19, 14
  88. 88. A separate system is needed to supervise and manage processes. ©Typesafe 2014 – All Rights Reserved 88 Wednesday, November 19, 14
  89. 89. Use Actors or... ©Typesafe 2014 – All Rights Reserved 89 Wednesday, November 19, 14
  90. 90. https://github.com/Netflix/Hystrix ©Typesafe 2014 – All Rights Reserved 90 Wednesday, November 19, 14
  91. 91. •Better separation of concerns. •Failure can be delegated to a separate component. •Strategy for failure handling can be pluggable. •Better scalability. ©Typesafe 2014 – All Rights Reserved 91 Wednesday, November 19, 14
  92. 92. Conclusions ©Typesafe 2014 – All Rights Reserved 92 Wednesday, November 19, 14
  93. 93. ©Typesafe 2014 – All Rights Reserved Actors 93 -Untyped interfaces. -More OOP than FP. -Overhead higher than function calls. Wednesday, November 19, 14
  94. 94. ©Typesafe 2014 – All Rights Reserved Actors 94 +Industry proven scalability and resiliency. +Native asynchrony. Best-in-class strategy for failure handling. Wednesday, November 19, 14
  95. 95. CSP, Rx, etc. ©Typesafe 2014 – All Rights Reserved 95 -Limited failure handling facilities. -Distributed channels? Wednesday, November 19, 14 I would include futures in the list of deriva8ves.
  96. 96. CSP, Rx, etc. ©Typesafe 2014 – All Rights Reserved 96 +Emphasize flow of control. +Typed channels. Optimal replacement for multithreaded (intra-process) programming. Wednesday, November 19, 14
  97. 97. Since we’re in a comedy club, let me finish by saying... ©Typesafe 2014 – All Rights Reserved 97 Wednesday, November 19, 14
  98. 98. You’ve been a great audience! ©Typesafe 2014 – All Rights Reserved 98 Wednesday, November 19, 14
  99. 99. I’m here all day! ©Typesafe 2014 – All Rights Reserved 99 Wednesday, November 19, 14
  100. 100. Don’t forget to tip your waitress! ©Typesafe 2014 – All Rights Reserved 100 Wednesday, November 19, 14
  101. 101. Try the veal! ©Typesafe 2014 – All Rights Reserved 101 Wednesday, November 19, 14
  102. 102. http://typesafe.com/reactive-big-data dean.wampler@typesafe.com ©Typesafe 2014 – All Rights Reserved Wednesday, November 19, 14 Photos from Jantar Mantar (“instrument”, “calcula8on”), the astronomical observatory built in Jaipur, India, by Sawai Jai Singh, a Rajput King, in the 1720s-­‐30s. He built four others around India. This is the largest and best preserved. All photos are copyright (C) 2012-­‐2014, Dean Wampler. All Rights Reserved.
  103. 103. Bonus Slides ©Typesafe 2014 – All Rights Reserved 103 Wednesday, November 19, 14
  104. 104. Communicating Sequential Processes Message passing via channels ©Typesafe 2014 – All Rights Reserved 104 Wednesday, November 19, 14 See h^p://en.wikipedia.org/wiki/Communica8ng_sequen8al_processes h^p://clojure.com/blog/2013/06/28/clojure-­‐core-­‐async-­‐channels.html h^p://blog.drewolson.org/blog/2013/07/04/clojure-­‐core-­‐dot-­‐async-­‐and-­‐go-­‐a-­‐code-­‐comparison/ and other references to follow.
  105. 105. ©Typesafe 2014 – All Rights Reserved 105 Wednesday, November 19, 14 Hoare’s book on CSP, originally published in ’85 aoer CSP had been significantly evolved from the ini8al programming language he defined in the 70’s to a theore8cal model with a well-­‐defined calculus by the mid 80’s (with the help of other people, too). The book itself has been subsequently refined. The PDF is available for free.
  106. 106. ©Typesafe 2014 – All Rights Reserved 106 Wednesday, November 19, 14 Modern treatment of CSP. Roscoe helped transform the original CSP language into its more rigorous, process algebra form, which was influenced by Milner’s Calculus of Communica8ng Systems work. This book’s PDF is available free. This treatment is perhaps more accessible than Hoare’s book.
  107. 107. CSP Operators ©Typesafe 2014 – All Rights Reserved 107 Wednesday, November 19, 14
  108. 108. a⟶P ©Typesafe 2014 – All Rights Reserved Prefix 108 A process communicates event a to its environment. Afterwards the process behaves like P. Wednesday, November 19, 14 A process communicates
  109. 109. Deterministic Choice a⟶P ☐ b⟶Q ©Typesafe 2014 – All Rights Reserved 109 A process communicates event a or b to its environment. Afterwards the process behaves like P or Q, respectively. Wednesday, November 19, 14
  110. 110. Nondeterministic Choice a⟶P ⊓ b⟶Q ©Typesafe 2014 – All Rights Reserved 110 The process doesn’t get to choose which is communicated, a or b. Wednesday, November 19, 14
  111. 111. Interleaving P ||| Q ©Typesafe 2014 – All Rights Reserved 111 Completely independent processes. The events seen by them are interleaved in time. Wednesday, November 19, 14
  112. 112. Interface Parallel P |[{a}]| Q ©Typesafe 2014 – All Rights Reserved 112 Represents synchronization on event a between P and Q. Wednesday, November 19, 14
  113. 113. a⟶P {a} ©Typesafe 2014 – All Rights Reserved Hiding 113 A form of abstraction, by making some events unobservable. P hides events a. Wednesday, November 19, 14
  114. 114. References ©Typesafe 2014 – All Rights Reserved 114 Wednesday, November 19, 14
  115. 115. ©Typesafe 2014 – All Rights Reserved 115 Wednesday, November 19, 14 Lots of interes8ng prac8cal ideas for combining func8onal programming and reac8ve approaches to class Domain-­‐Driven Design by Eric Evans.
  116. 116. ©Typesafe 2014 – All Rights Reserved 116 Wednesday, November 19, 14 Hoare’s book on CSP, originally published in ’85 aoer CSP had been significantly evolved from a programming language to a theore8cal model with a well-­‐defined calculus. The book itself has been subsequently refined. The PDF is available for free.
  117. 117. ©Typesafe 2014 – All Rights Reserved 117 Wednesday, November 19, 14 Modern treatment of CSP. Roscoe helped transform the original CSP language into its more rigorous, process algebra form, which was influenced by Milner’s Calculus of Communica8ng Systems work. This book’s PDF is available free. The treatment is more accessible than Hoare’s book.
  118. 118. ©Typesafe 2014 – All Rights Reserved 118 Wednesday, November 19, 14 A survey of theore8cal models of distributed compu8ng, star8ng with a summary of lambda calculus, then discussing the pi, join, and ambient calculi. Also discusses the actor model. The treatment is somewhat dry and could use more discussion of real-­‐world implementa8ons of these ideas, such as the Actor model in Erlang and Akka.
  119. 119. ©Typesafe 2014 – All Rights Reserved 119 Wednesday, November 19, 14 Gul Agha was a grad student at MIT during the 80s and worked on the actor model with Hewi^ and others. This book is based on his disserta8on. It doesn’t discuss error handling, actor supervision, etc. as these concepts . His thesis, h^p://dspace.mit.edu/handle/1721.1/6952, the basis for his book,h^p://mitpress.mit.edu/books/actors See also Paper for a survey course with Rajesh Karmani, h^p://www.cs.ucla.edu/~palsberg/course/cs239/papers/karmani-­‐agha.pdf
  120. 120. ©Typesafe 2014 – All Rights Reserved 120 Wednesday, November 19, 14 Survey of the classic graph traversal algorithms, algorithms for detec8ng failures in a cluster, leader elec8on, etc.
  121. 121. ©Typesafe 2014 – All Rights Reserved 121 Wednesday, November 19, 14 A less comprehensive and formal, but more intui8ve approach to fundamental algorithms.
  122. 122. ©Typesafe 2014 – All Rights Reserved 122 Wednesday, November 19, 14 Comprehensive and somewhat formal like Raynal’s book, but more focused on modeling common failures in real systems.
  123. 123. ©Typesafe 2014 – All Rights Reserved 123 Wednesday, November 19, 14 1992: Yes, “Reac8ve” isn’t new ;) This book is lays out a theore8cal model for specifying and proving “reac8ve” concurrent systems based on temporal logic. While its goal is to prevent logic errors, It doesn’t discuss handling failures from environmental or other external causes in great depth.
  124. 124. ©Typesafe 2014 – All Rights Reserved 124 Wednesday, November 19, 14 1988: Another treatment of concurrency using algebra. It’s not based on CSP, but it has similar constructs.
  125. 125. ©Typesafe 2014 – All Rights Reserved 125 Wednesday, November 19, 14 A recent text that applies combinatorics (coun8ng things) and topology (proper8es of geometric shapes) to the analysis of distributed systems. Aims to be pragma8c for real-­‐world scenarios, like networks and other physical systems where failures are prac8cal concerns.
  126. 126. ©Typesafe 2014 – All Rights Reserved 126 Wednesday, November 19, 14 h^p://mitpress.mit.edu/books/engineering-­‐safer-­‐world Farther afield, this book discusses safety concerns from a systems engineering perspec8ve.
  127. 127. ©Typesafe 2014 – All Rights Reserved Others 127 • Rob Pike: Go Concurrency Patterns –http://www.youtube.com/watch? v=f6kdp27TYZs&feature=youtu.be • Comparison of Clojure Core Async and Go –http://blog.drewolson.org/blog/2013/07/04/ clojure-core-dot-async-and-go-a-code-comparison/ Wednesday, November 19, 14

×