Into the Reactive world with Reactor

Resource Link: https://namila.me/blog/2021-02/into-the-reactive-world-with-reactor/

Transcript

1. Into the Reactive World WITH REACTOR Namila Bandara Software Engineer
3. Content •Taking About • First idea • Brief Intro • Reactive stream specs • Operators in Reactor • Hot and Cold Publishers • Threading and Schedulers • Handling Errors • Testing Reactive Streams •Not Talking About • Back-Pressure Handling • Context Passing
4. First Idea Ex: X calling Y Ways of Organizing • Blocking o X waits for Y • Non-Blocking o X returns and work, polling Y results Type of Operations • Synchronous - o X waits for Y • Asynchronous o X return before finish, can operate and won't come back until Y calls X o Callbacks, Future/Promises
8. Observer Pattern • Create an Observable Subject • Add Observers to observe the subject • Do change on Subject • Send Notification to all observers • Mainly used for event-driven system • Reactor pattern derived from this
9. Reactive Programming “Reactive programming is about non-blocking, event- driven applications that scale with a small number of threads with backpressure as a key ingredient that aims to ensure producers do not overwhelm consumers.”
10. Brief Intro • Says originated on 1970s and earlier. • From Microsoft Reactive extension library, Netflix developed the RX model for internal work •Twitter, Netflix, Red Hat and few more Corp. established Reactor Stream Org and declared a common model; The Reactive Manifesto • Reactive programming is a style micro-architecture involving intelligent routing and consumption of events, all combining to change behavior • FRP has strong affinity with high-performance, concurrency, asynchronous operations and non blocking I/O •Use cases: External service calls, high concurrency message consumers •Libraries/Frameworks: Reactive Streams, RxJava, Akka, Reactor
11. Reactive Stream Specs Subscription Processor • Publisher: A source of data.It optionally provides for 2 terminal events: error and completion. • Subscriber: A consumer of a data sequence. It receives a subscription on initialization to request how many data it wants to process next. • Subscription: A small tracker passed on initialization to the Subscriber. It controls how many data we are ready to consume and when do we want to stop consuming (cancel). • Processor: A marker for components that are both Subscriber and Publisher!
12. Comparison
13. Project Reactor • Two types; • Mono<T> • Emits 0 or 1 elements • Flux<T> • Emits 0 or n elements
14. Mono<T> Read More:Mono (reactor-core 3.4.1) (projectreactor.io)
15. Flux<T> Read More: Flux (reactor-core 3.4.1) (projectreactor.io)
17. Operators Creational • FromArray, fromIterable, fromCallable, interval Transformational • flatmap, map, concatmap, switchmap Combining • zip, zipwith, merge Aggregate • Count, toList, reduce Filtering • Distinct, skip, take, ignoreElements
18. Flatmap vs Map • Flatmap – Transform emitted item asynchronously and return Mono<T>/Flux<T> • Map – Transform emitted item by applying a synchronous function and return an item
19. “Nothing Happens Until You Subscribe” Publisher (Mono/Flux) Operation Operation Operation Subscription Two stages: Assembly time and Subscription time
20. • Once subscribe, signaling is propagated backward through chain of operators until to source operator 1->2->3->4->5 • Once signal reach the source it triggers it and start generating the data • Data starts to flow from top to bottom (execution time) 5>4>3>2>1 and print the emitted item
21. Hot and Cold Publishers
22. Cold Publishers (Pull based) • Flux and Mono are cold publishers. • Lazy and only generate when there is a subscription • Generate a new data for each subscriptions
23. Hot Publisher (Push based) • When created, begins generating items and emits them immediately. • No need of subscriptions to generate data. Read More: Flight of the Flux 1 - Assembly vs Subscription (spring.io)
24. Threading and Schedulers SCHEDULERS, SUBSCRIPTIONON AND PUBLISHON
25. “Reactor considered to be concurrency-agnostic” It does not enforce a concurrency model; you can make it concurrent or not
26. Concurrency vs Parallelism •Concurrency is when two tasks can start, run, and complete in overlapping time periods. •Parallelism is when tasks literally run at the same time, eg. on a multi-core processor Read More: What is the difference..? - Stack Overflow
27. Threading in Reactor •Schedulers determines where the execution happens, similar to an Executor Service. •Two main ways of switching execution context on reactor; • PublishOn • SubescribeOn •Both take schedulers and switch execution context to that scheduler. •Placement on PublishOn on chain matters while Subscribeon does not.
28. Schedulers •Scheduler determines the execution model and where the execution happens •More like an Executor service with workers (not same) •Workers schedule tasks •Multiple schedulers available on reactor •Schedulers.new*** returns a new instance Immediate • An empty scheduler object. Not switching threads Single • Task runs on unique executor service Elastic • For long lived tasks (IO), spawn threads without a limit Bounded Elastic • Same as elastic, but spawn limited threads Parallel • For short living CPU intensive tasks. Can execute N tasks parallel (N = # CPUs)
29. Subscribe On •Applies to subscribing process
30. 1. SubscribeOn() changes where sequence subscription happens 2. Which also where data flows initially
31. Publish On •Once apply the operators after the publishOn changes the threads •Can assign Schedulers
32. 1. Thread calling subscribe(), where data flows initially 2. After publishOn() data flows on Thread 2
33. What happens if I use both together on the same publisher chain ??
34. Read more: Flight of the Flux 3 - Hopping Threads and Schedulers (spring.io) 1. Subscribe called on current thread, but subscription rapidly switched to subscriptionOn thread 2. Operator 1 & 2 executed on Scheduler used on SubscriberOn 3. Found publishOn, context switching and Operator 4 and subscribe consumer execute on that thread
35. Threading in a nutshell •publishOn forces the next operator (and possibly subsequent operators after the next one) to run on a different thread. •SubscribeOn forces the previous operator (and possibly operators prior to the previous one) to run on a different thread. •Once you switch the threads, you can't go back to MAIN thread again. (Java can't submit tasks to main threads)
36. Handling Errors CATCHING, THROWING, RE-TRYING
37. Handling Errors •Try catch can't handle errors occurred on reactive streams. •Errors are terminal events. • When an error occurred , it terminates sequence and propagate down the chain of operators to last subscriber and to its onError method. • When error occurred, even error handling was used, it does not continue the original sequence • Converts to onError signal and propagate as a new sequence by replacing the current.
38. • Try catch can't catch the exception •Exception is handled by reactor core itself
40. Error Handling Operators onErrorReturn • Returns a static fallback value (Catch and return a static default value) onErrorResume • Instead of single fallback value, handle the error safer way. (Catch and execute an alternative path with a fallback method) onErrorMap • Catch an error and rethrow it with a business exception doOnError • React to the error without changing the sequence. (Catch, log an error-specific message, and re-throw) doFinally • Equals to finally block. Read more: Error Handling Operators
41. Retry again? • When an error occurred, as mentioned on the previous slides, upstream get canceled and new Error stream is propagated down the sequence. •But we can RETRY if we face an error •Retry() will re-subscribe to upstream publisher. • It make a new sequence (original sequence is terminated) and re-run the publisher chain. •RetryWhen() gives ability to control the retry conditions Read more: Retry Operations
42. • Generate flux and take only 5 emitting values •Mapping until < 2 •Else throwing, then retrying Once •Re-running the flux in new sequence •Exception occurs, no retrying again. •Print exception on STDERR
43. Testing Reactive Streams STEPVERIFIER, TESTPUBLSIHER
44. Testing • All the testing elements and supports are available on reactor-test artifact • By using reactor-test, we can; • Test sequence of a given scenario by StepVerifier • Produce the test data in order to test a sequence by TestPublisher
45. StepVerifier • StepVerifier subscribe to test Flux and plays the sequence •As long as assertion match, the testing is succeeded. •If an assertion fails, it will throw “Assertion Error”
46. With Virtual Time • For long time-based operators, use withvirtualtime builder • Replace schedulers by virtualTimeScheduler • Must initiate publisher inside the lambda function to ensure the time guarantee. Read More: Reactive Stream Testing
47. Test Publisher
48. Q&A Time
49. More References •Notes on Reactive Programming Part I: The Reactive Landscape (spring.io) •Flight-of-the-flux •Reactor by Example (infoq.com) •Avoiding reactor meltdown (infoq.Com) •Projectreactor-dot-io-reactor3-intro •Presentation: reactive: do. Or do not. There is no try. - Speaker deck •Project reactor release docs •Asynchronous programming. Cooperative multitasking - blog | luminousmen •To learn reactive concepts (rxjava) •RX flow. My flow of learning rx | medium •Flight of the flux 2 - debugging caveats (spring.Io) •Intro to reactor core | baeldung •Applying Reactive Programming to Existing Applications - Reactive Programming with RxJava [Book] (oreilly.com)
50. Session Videos •https://youtu.be/CLODaggw-NQ
51. Thank You!