Into the Reactive World WITH REACTOR Namila Bandara Software Engineer

No content

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

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

No content

No content

No content

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

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.”

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

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!

Comparison

Project Reactor • Two types; • Mono • Emits 0 or 1 elements • Flux • Emits 0 or n elements

Mono Read More:Mono (reactor-core 3.4.1) (projectreactor.io)

Flux Read More: Flux (reactor-core 3.4.1) (projectreactor.io)

No content

Operators Creational • FromArray, fromIterable, fromCallable, interval Transformational • flatmap, map, concatmap, switchmap Combining • zip, zipwith, merge Aggregate • Count, toList, reduce Filtering • Distinct, skip, take, ignoreElements

Flatmap vs Map • Flatmap – Transform emitted item asynchronously and return Mono/Flux • Map – Transform emitted item by applying a synchronous function and return an item

“Nothing Happens Until You Subscribe” Publisher (Mono/Flux) Operation Operation Operation Subscription Two stages: Assembly time and Subscription time

• 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

Hot and Cold Publishers

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

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)

Threading and Schedulers SCHEDULERS, SUBSCRIPTIONON AND PUBLISHON

“Reactor considered to be concurrency-agnostic” It does not enforce a concurrency model; you can make it concurrent or not

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

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.

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)

Subscribe On •Applies to subscribing process

1. SubscribeOn() changes where sequence subscription happens 2. Which also where data flows initially

Publish On •Once apply the operators after the publishOn changes the threads •Can assign Schedulers

1. Thread calling subscribe(), where data flows initially 2. After publishOn() data flows on Thread 2

What happens if I use both together on the same publisher chain ??

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

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)

Handling Errors CATCHING, THROWING, RE-TRYING

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.

• Try catch can't catch the exception •Exception is handled by reactor core itself

No content

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

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

• 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

Testing Reactive Streams STEPVERIFIER, TESTPUBLSIHER

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

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”

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

Test Publisher

Q&A Time

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)

Session Videos •https://youtu.be/CLODaggw-NQ

Thank You!