Presentation held at the Parallel Conference in Karlsruhe, Germany, on May 6, 2014. Apart from the slides, the presentation featured a demo of RxJava, highlighting its strengths and some of its current limitations.
couple client and service (often block) − Asynchronous means the client can decide if and where to block ! − Non-blocking − Blocking APIs may require large numbers of threads (often coupled to users) − Wastes CPU resources (context switches, scheduling) − Non-blocking frees threads to do new work − Define worker thread pools based on resources ! − Share nothing ! − Loose coupling Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
an asynchronously computed value ! − Promise: A future with additional features − May be completed in various ways (e.g., by a setter) − Enables composition (one promise completes another) ! − (Functional) Reactive Programming − Futures and promises taking to the extreme
and service are decoupled ! − Service API keeps control over its implementation ! − Client decides how its subscription should behave (e.g., timeouts) ! − Note: The „client“ may be another service having its own clients − Not necessarily a human or a browser
its consumer(s) − Due to inversion of control when going from sync to async ! − Consumers need a mechanism for „back pressure“ − Tell the producer how much data you can handle − Similar to, e.g., receiver window in TCP From: http://www.reactive-streams.org
− Parallelize tasks within services ! − Choose algorithms with small variance in execution time − Predictable execution time for some target percentile ! − Use explicit and bounded queues ! − Use circuit breakers that monitor target metrics and react on violation − fail-fast and reject, return partial results, or delegate to another service − e.g., for input queues, reject requests when the queue is full Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
in the presence of unexpected failures − software, hardware, human ! − Distribute the system ! − Use bulkheading ! ! ! ! − Let supervisors handle failure − separate failure handling from the actual business logic of the service Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview. From: http://www.reactivemanifesto.org
based on load ! − Distribute requests to various instances of the services ! − The more stateless services, the better ! − Measure load at run time and react accordingly − But: No reason to forego capacity planning Based on: Roland Kuhn, Jamie Allen. „Reactive Design Patterns“. Manning. Chapter 1 preview.
reactive traits much better than reactive programming does − Asynchronous, non-blocking, and event-driven by definition − Supervisors and „let it crash“ − Distributed − Easily scalable ! − But maybe too „heavyweight“ for some problems within services − Often, stateless actors don’t suffice or get highly complex ! − Promising approach: Combine actors and reactive programming − Actors for the backbone and cluster „infrastructure“ − Reactive Programming inside the nodes
− Well addressed by the actor model and reactive programming approaches ! − Building reactive applications requires different thinking ! − Helped by various reactive frameworks, in particular on the JVM ! − Brings up the topic of essential complexity vs. incidental complexity
Data? − If reactive applications focus so much on availability, what about consistency − CAP suggests you need to choose between C and A ! − But: Even with CAP you can have C and A most of the time − You just need to have a reliable strategy for detecting and handling partitions − http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed ! − Note: There is also a „Reactive Programming“ in the context of databases − http://www.espressologic.com/reactive-programming-database-logic/ − Don’t confuse it with the „Functional Reactive Programming“ we have seen
peschlowp
kameitomohiro
kyohmizu
.png){kind=avatar}
customercloud
itkq
ozawa
ks91
hr01
minorun365
wsvincent
haruki_uiru
tarotaro0129
uhyo
malarkey
danielanewman
michaelherold
bryan
garrettdimon
notwaldorf
soudai
addyosmani
dougneiner
keithpitt
bkeepers
samanthasiow
