Java Threads Rx Java Spring WebFlux WebSockets

Slide 1

Slide 1 text

@arafkarsh arafkarsh Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh AI / ML Generative AI LLMs, RAG 6+ Years Microservices Blockchain 8 Years Cloud Computing 8 Years Network & Security 8 Years Distributed Computing 1 Concurrency & Parallelism Immutability, Atomic Operations Semaphore, Monitor, Mutex (ReentrantLock), Count Down Latch, Cyclic Barrier, Exchanger, Phaser Threads, Thread Pool, Thread Groups Future / Completable Future Reactive Programming Rx Java / WebFlux / Server-Side Events, Web Sockets Microservices Architecture Series Part 4 of 15 To Build Cloud Native Apps Composable Enterprise Architecture

Slide 2

Slide 2 text

@arafkarsh arafkarsh 2 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb Cloud-Native Architecture

Slide 3

Slide 3 text

@arafkarsh arafkarsh 3 Source: https://arafkarsh.medium.com/embracing-cloud-native-a-roadmap-to-innovation-a6b06fe3a9fb

Slide 4

Slide 4 text

@arafkarsh arafkarsh 4 Slides are color coded based on the topic colors. Concurrency / Parallelism Immutability / Atomic Synchronization Semaphore / Mutex 1 Thread Pools Thread Groups Future Completable Future 2 Rx Java Design Patterns Observables Operators 3 Spring Reactive WebFlux Mono / Flux SSE / Web Sockets 4

Slide 5

Slide 5 text

@arafkarsh arafkarsh 0 Code Setup o SpringBoot 2.7.2 (MVC) / SpringBoot 3.1.0 (WebFlux) o Java 8 for Compile and Java 17 to run o H2 DB or PostgreSQL database 5

Slide 6

Slide 6 text

@arafkarsh arafkarsh Package Structure 6 Source: https://github.com/arafkarsh Threads / Rx Java 2: https://github.com/arafkarsh/fusion-sky-threads-rx-java Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc Spring MVC & Security: https://github.com/arafkarsh/ms-springboot-272-vanilla

Slide 7

Slide 7 text

@arafkarsh arafkarsh Codebase 7 Source: https://github.com/arafkarsh/ms-quickstart

Slide 8

Slide 8 text

@arafkarsh arafkarsh Agile Scrum (4-6 Weeks) Developer Journey Monolithic Domain Driven Design Event Sourcing and CQRS Waterfall Optional Design Patterns Continuous Integration (CI) 6/12 Months Enterprise Service Bus Relational Database [SQL] / NoSQL Development QA / QC Ops 8 Microservices Domain Driven Design Event Sourcing and CQRS Scrum / Kanban (1-5 Days) Mandatory Design Patterns Infrastructure Design Patterns CI DevOps Event Streaming / Replicated Logs SQL NoSQL CD Container Orchestrator Service Mesh

Slide 9

Slide 9 text

@arafkarsh arafkarsh Application Modernization – 3 Transformations 9 Monolithic SOA Microservice Physical Server Virtual Machine Cloud Waterfall Agile DevOps Source: IBM: Application Modernization > https://www.youtube.com/watch?v=RJ3UQSxwGFY Architecture Infrastructure Delivery Modernization 1 2 3

Slide 10

Slide 10 text

@arafkarsh arafkarsh Problem 10 Is Concurrency == Parallelism?

Slide 11

Slide 11 text

@arafkarsh arafkarsh 1 Concurrency & Parallelism o Understanding Concurrency o Understanding Parallelism o Immutability / Atomic Operations o Handling Shared Resources 11

Slide 12

Slide 12 text

@arafkarsh arafkarsh Concurrency 12 Concurrency is the concept of managing multiple tasks by allowing them to overlap, giving the appearance that the tasks run simultaneously. It does not necessarily imply that the tasks are executed at the same time. Instead, it focuses on dealing with many things simultaneously, even if only one task is being processed at any moment. In a single-core system, accurate parallel execution is not possible. However, concurrency can still be achieved through time-slicing or multitasking, where the CPU switches between different tasks rapidly, giving the illusion of simultaneous execution.

Slide 13

Slide 13 text

@arafkarsh arafkarsh Parallelism 13 Parallelism, on the other hand, is the execution of multiple tasks or computations at the exact same time. This requires a multi-core processor, where tasks are assigned to different cores and processed simultaneously. Parallelism is a specific form of concurrency where the overlapping tasks genuinely run simultaneously, not just appearing to do so. It is beneficial in computations or operations that can be divided into independent sub-tasks that can be processed simultaneously.

Slide 14

Slide 14 text

@arafkarsh arafkarsh Comparison 14 Feature Concurrency Parallelism Definition Managing multiple tasks, allowing them to overlap or run out of order. Executing multiple tasks at the exact same time. Simultaneous Execution Not required; tasks may appear to run simultaneously but don't have to. Requires true simultaneous execution. Use Case Efficiently handling multiple tasks, e.g., I/O-bound tasks. Speeding up computation-intensive tasks by dividing into independent parts. Hardware Requirement Can be achieved on single-core or multi- core processors. Generally requires multi-core processors. Synchronization Often requires complex synchronization to manage shared resources. Easier when tasks are independent and don't need to share resources. Performance Goal Maximizing responsiveness, managing many tasks at once. Maximizing computational throughput, completing tasks faster. Example Web server handling multiple client requests. Image processing uses multiple cores to process different parts of an image simultaneously.

Slide 15

Slide 15 text

@arafkarsh arafkarsh Summary 15 • Concurrency focuses on managing multiple tasks, giving the appearance of simultaneous execution. It is more about structure, dealing with multiple things at once, and can be applied even on a single-core system. • Parallelism is a specific form of concurrency that deals with executing several tasks or computations at the exact same time, typically on a multi- core system. Understanding these distinctions is vital in software architecture, especially in cloud-native environments where efficient resource utilization and scalability are critical. It helps choose the right strategy for different workloads, from I/O-bound tasks that may benefit from concurrency to CPU- bound tasks that can be accelerated with parallelism.

Slide 16

Slide 16 text

@arafkarsh arafkarsh Immutability o Object Immutability o Atomic Operations 16

Slide 17

Slide 17 text

@arafkarsh arafkarsh Immutable Objects 17 Immutable objects are objects whose state cannot be changed after creation. They provide several benefits, especially in a multithreaded environment: • Thread Safety: Since their state cannot change, they can be safely shared across threads without synchronization. • Predictability: An immutable object’s behavior is easier to reason, leading to more maintainable and less error- prone code.

Slide 18

Slide 18 text

@arafkarsh arafkarsh Atomic Operations on Primitives 18 Atomic operations ensure that operations are completed without being interrupted by other threads, thereby avoiding inconsistencies. • Atomic Classes in Java: Java provides classes like AtomicInteger, AtomicLong, etc., in the java.util.concurrent.atomic package that offers methods for performing atomic operations on primitive variables. • Visibility: Atomic classes also ensure that changes to a variable are visible across threads. • Efficiency: They typically offer better performance compared to synchronized blocks.

Slide 19

Slide 19 text

@arafkarsh arafkarsh Compare and Swap (CAS) 19 CAS is a fundamental building block for many atomic operations and concurrent algorithms. It's a hardware-level instruction supported by many processors. • Operation: CAS takes three parameters – a memory location (V), the expected current value (A), and the new value (B). If the current value at location V equals A, CAS updates V to B. Otherwise, it does nothing. • Atomicity: The comparison and the update happen as a single atomic operation. If another thread changes the value at location V after the comparison but before the update, the operation will fail. • Usage in Java: Classes like AtomicInteger use CAS internally to provide atomic operations.

Slide 20

Slide 20 text

@arafkarsh arafkarsh Example 1: Non-Thread Safe Integer Arithmetic 20 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 21

Slide 21 text

@arafkarsh arafkarsh Why is the Example 1 Not Thread safe? 21 The operation x++ seems like a single operation, but it's comprised of three separate steps: 1. Read: Read the current value of x. 2. Increment: Increment the read value by 1. 3. Write: Write the new value back to x. These three operations are not atomic, meaning multiple threads can interleave in undesirable ways. Here's an example with two threads: • Thread 1 reads x (value is 0). • Thread 2 reads x (still 0 because Thread 1 still needs to update it). • Thread 1 increments and writes the value (now 1). • Thread 2 increments the old value it read (0 + 1 = 1) and writes it back. Both threads intended to increment the counter, but it only got incremented once because of the race condition.

Slide 22

Slide 22 text

@arafkarsh arafkarsh Example 2: Thread Safe Integer Arithmetic 22 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 23

Slide 23 text

@arafkarsh arafkarsh Why Example 2 thread safe? 23 AtomicInteger uses low-level synchronization mechanisms, often employing Compare And Swap (CAS), to ensure that the read-modify-write operations are done atomically. When you call incrementAndGet() on an AtomicInteger, it ensures that the underlying value is incremented so that no two threads can interfere with each other’s updates. This way, you avoid the race condition illustrated above. So, in a multithreaded environment, using AtomicInteger would ensure that each thread correctly increments the value without corrupting it, thereby making the operation thread-safe. Understanding these subtleties is particularly important in concurrent and distributed systems, as you might encounter in your work with Cloud Native Architecture and Security. Using thread-safe constructs like AtomicInteger helps to build more robust and scalable systems.

Slide 24

Slide 24 text

@arafkarsh arafkarsh Handling Shared Resources o Synchronization o Semaphores / Monitor / Mutex / Count Down Latch o Cyclic Barrier / Exchanger / Phaser 24

Slide 25

Slide 25 text

@arafkarsh arafkarsh Synchronization 25 Synchronization is a general concept that refers to coordinating the execution of multiple threads to ensure that they can safely access shared resources or perform actions in a specific sequence. Without proper synchronization, there can be race conditions, where the program’s behavior depends on the threads’ relative timing, leading to unpredictable or erroneous behavior.

Slide 26

Slide 26 text

@arafkarsh arafkarsh Compare 26 Feature Synchronization Semaphore Monitor Mutex Primary Purpose Coordinate multiple threads' execution. Control access to a common resource by threads. Mutual exclusion + ability to wait for conditions. Enforce mutual exclusion. Mechanism General concept; various techniques. Counting mechanism; Wait and Signal operations. Mutual exclusion + Condition Variables. Lock/Unlock operations. Complexity Depends on the specific technique used. Relatively simple; versatile. More complex; high-level synchronization. Simple; specifically for mutual exclusion. Use Cases Various; depends on the situation. Resource management, flow control. Complex synchronization, producer-consumer problems. Protecting critical sections from race conditions. Java Semaphore Java Thread Wait & Notify ReentrantLock

Slide 27

Slide 27 text

@arafkarsh arafkarsh Semaphore 27 A Semaphore is a synchronization primitive that controls multiple threads’ access to a shared resource. It maintains a count representing the number of available resources: • Wait (P operation): If the count is greater than zero, it is decremented, and the thread continues. If the count is zero, the thread blocks until it becomes greater than zero. • Signal (V operation): This operation increments the count, potentially unblocking a waiting thread. Semaphores can implement various synchronization patterns, including mutual exclusion (MutEx using a binary semaphore) or limiting concurrency to a fixed number of threads.

Slide 28

Slide 28 text

@arafkarsh arafkarsh Semaphore Java Example 28 Only one thread can acquire the lock at any given time because only one permit is available. Subsequent calls to acquire() from other threads will be blocked until the thread that holds the lock calls release(). Initializing the semaphore with 10 permits means up to 10 threads can concurrently acquire the lock. Use cases 1. Thread Pools 2. Database Connection Pools Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 29

Slide 29 text

@arafkarsh arafkarsh Monitor 29 A Monitor is a synchronization construct that allows threads to have both mutual exclusion and the ability to wait for a certain condition to become true. Monitors provide: • Mutual Exclusion: Only one thread at a time can execute inside the monitor, ensuring controlled access to shared resources. • Condition Variables: These allow threads to wait inside the monitor for specific conditions to be met and to signal other threads when conditions have changed. In many programming languages, Monitors are implemented using objects and associated lock mechanisms, and they provide a high-level way to manage concurrent access to shared resources.

Slide 30

Slide 30 text

@arafkarsh arafkarsh Monitor Java Example 30 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 31

Slide 31 text

@arafkarsh arafkarsh Java notify() 31 In Java, both notify() and notifyAll() methods are used to wake up threads waiting for a condition to be met, typically within a synchronized block or method. They are part of Java's built-in synchronization support, often termed "intrinsic locks" or "monitors.” notify() When notify() is called, it wakes up a single waiting thread from the waiting pool associated with the object's monitor. If multiple threads are waiting, it chooses one thread to wake up, but it's not specified which one will be chosen; the choice is arbitrary and implementation-dependent. Behavior with Multiple Waiting Threads: • Wake Up: Only one among multiple waiting threads is woken up. • Choice: Which thread will be woken up is not deterministic; it depends on the scheduling policy.

Slide 32

Slide 32 text

@arafkarsh arafkarsh Java notifyAll() 32 When notifyAll() is called, it wakes up all the threads currently waiting on that object's monitor. Behavior with Multiple Waiting Threads: • Wake Up: All waiting threads are woken up. • Competition: After waking up, they will compete for the lock. Only one will get it, and the others will return to waiting. Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 33

Slide 33 text

@arafkarsh arafkarsh MutEx 33 A Mutex is a synchronization primitive specifically designed to enforce mutual exclusion. When a thread acquires a Mutex (also known as locking the Mutex), no other thread can access the critical section protected by that Mutex until the original thread releases it: • Lock: A thread locks the Mutex to gain exclusive access to the critical section. • Unlock: The thread unlocks the Mutex when it is done, allowing other threads to enter the critical section. A Mutex ensures that only one thread at a time can execute the code that accesses shared resources, preventing race conditions.

Slide 34

Slide 34 text

@arafkarsh arafkarsh Mutex: ReentrantLock – Java Example 34 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 35

Slide 35 text

@arafkarsh arafkarsh Conditions with Mutex - ReentrantLock 35 The ReentrantLock class in Java's java.util.concurrent.locks package allows for more flexible and fine-grained control over synchronization than synchronized blocks. One of its powerful features is the use of Condition objects, which allow threads to wait for specific conditions to be met before proceeding. A Condition object is often used as a replacement for the Object monitor methods wait(), notify(), and notifyAll() when using ReentrantLock. Example: Producer-Consumer with ReentrantLock and Condition The example that simulates a producer-consumer relationship. The producer adds items to a shared LinkedList, and the consumer removes them. The producer and consumer operate concurrently and coordinate using ReentrantLock and Condition.

Slide 36

Slide 36 text

@arafkarsh arafkarsh ReentrantLock with Condition Example 36 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 37

Slide 37 text

@arafkarsh arafkarsh Understanding the Producer Code 37 • int value = 0;: This initializes the value to be inserted into the list to 0. • while (value < totalItems ) { ... }: The producer will produce until it reaches the max no. of items defined. • lock.lock();: This acquires the lock. After this point, only one thread can execute the code inside the try block until lock.unlock(); is called. • while (list.size() == capacity) { ... }: If the list is full (the size is equal to the capacity), the producer will enter this while loop. Inside this loop, notFull.await(); is called, which makes the producer thread wait until the notFull condition is met (i.e., the list is not full). In simpler terms, the producer will pause and release the lock, allowing other threads to acquire it. When the consumer consumes an item and calls notFull.signal();, the waiting producer is awakened, and the loop condition (list.size() == capacity) is re-evaluated. • list.add(value++);: Adds a value to the list and then increments it for the next round of production. • notEmpty.signal();: This signals any waiting consumer threads that the list is no longer empty, and they can proceed to consume items. • finally { lock.unlock(); }: Whether or not an exception is thrown inside the try block, the lock will be released, allowing other threads to acquire it.

Slide 38

Slide 38 text

@arafkarsh arafkarsh ReentrantLock with Condition Example 38 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 39

Slide 39 text

@arafkarsh arafkarsh ReadWriteLock 39 The ReadWriteLock interface in Java provides a pair of locks for read and write operations. A ReadWriteLock allows multiple threads to read a shared resource concurrently, but only one can write to it at any given time. This can result in better performance than using a single, mutual exclusion lock. 1. Read Locks: Multiple threads can acquire read locks as long as no thread holds a write lock. 2. Write Locks: Only one thread can acquire a write lock, and no other thread can hold either a read or write lock during this time. 3. Fairness Policy: ReadWriteLock implementations, like ReentrantReadWriteLock, can be constructed to follow a fairness policy, where they favor granting access to the longest-waiting thread, whether it is a reader or writer. 4. Reentrant Capabilities: The ReentrantReadWriteLock allows threads to re-enter any lock (read or write) they already hold.

Slide 40

Slide 40 text

@arafkarsh arafkarsh ReadWriteLock 40 5. Lock Downgrading: A writer can downgrade to a reader lock without releasing the write lock, allowing a more graceful transition from write to read operations. 6. Separate Conditions: The write lock provides the same Condition support as ReentrantLock, allowing you to manage conditional synchronization. 7. Non-Blocking tryLock(): Both read and write locks offer a non- blocking tryLock() method to attempt lock acquisition without blocking. 8. Timed Lock Waits: The ReadWriteLock supports timed lock waits. A thread can attempt to acquire a lock for a specified maximum time.

Slide 41

Slide 41 text

@arafkarsh arafkarsh ReadWriteLock – Example 41 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 42

Slide 42 text

@arafkarsh arafkarsh ReadWriteLock – Example 42 The readResource method acquires a read lock, reads the sharedResource variable, and then releases the read lock. The writeResource method acquires a write lock, updates the sharedResource variable, and then releases the write lock. Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 43

Slide 43 text

@arafkarsh arafkarsh Count Down Latch 43 The CountDownLatch class in Java's java.util.concurrent package serves as a synchronization mechanism that allows one thread to wait for one or more threads before it starts processing. • The latch is initialized with a count, which is decremented using the countDown() method. • The thread that needs to wait for other threads to finish uses the await() method, which blocks until the count reaches zero.

Slide 44

Slide 44 text

@arafkarsh arafkarsh Count Down Latch Example 44 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 45

Slide 45 text

@arafkarsh arafkarsh Count Down Latch Example 45 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 46

Slide 46 text

@arafkarsh arafkarsh Feature Comparison 46 Feature CountDownLatch Semaphore Monitor Mutex Purpose Coordination Allows one or more threads to wait until a set of operations in other threads completes. Resource Access Manages a set of permits for controlling access to a resource. Mutual Exclusion Encapsulates mutual exclusion and condition synchronization within an object. Mutual Exclusion Provides exclusive access to a section of code to only one thread at a time. Behavior One-way One-way countdown; once the count reaches zero, it cannot be reset. Two-way Permits can be acquired and released, making it a two-way mechanism. Conditional Uses wait(), notify(), and notifyAll() methods for coordination. Exclusive Acquire before entry and release after exit. Flexibility Low Less flexible in terms of reusability; once the latch reaches zero, it can't be used again. High More flexible as permits can be dynamically acquired and released. High Allows complex conditions for entering the synchronized block. Medium Generally, less flexible; and designed for mutual exclusion, not for signalling between threads. Reusability No Yes Yes Yes Common Use-Cases Initialization, Aggregation Waiting for initialization tasks to complete before application Startup, computation tasks to finish before aggregating results, etc. Resource Pooling, Rate Limiting Resource pooling, limiting concurrent access to a section of code, etc. Complex Conditions Producer-consumer problems, reader-writer problems, etc. Critical Sections Critical sections, singleton initialization, etc.

Slide 47

Slide 47 text

@arafkarsh arafkarsh Cyclic Barrier 47 1. Functionality: A synchronization aid that allows a set of threads to wait for each other to reach a common execution point. 2. Resettable: Can be reset and reused. 3. Actions at Barrier: You can specify a runnable action that is executed when the last thread reaches the barrier. 4. Use Cases: Useful in parallel algorithms where threads perform work in phases and each phase depends on the completion of the previous phase.

Slide 48

Slide 48 text

@arafkarsh arafkarsh Cyclic Barrier Example 48 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 49

Slide 49 text

@arafkarsh arafkarsh Cyclic Barrier Example 49 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 50

Slide 50 text

@arafkarsh arafkarsh Exchanger 50 1. Functionality: A synchronization point where threads can swap objects. 2. Pairing: Pairs up threads and allows them to exchange data. 3. Blocking: Threads will block until the paired thread arrives. 4. Use Cases: Useful in genetic algorithms, or any kind of algorithm where two threads need to swap data at a certain point

Slide 51

Slide 51 text

@arafkarsh arafkarsh Exchanger Example 51 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 52

Slide 52 text

@arafkarsh arafkarsh Phaser 52 1. Functionality: A more flexible and reusable synchronization barrier. 2. Phases: Supports multiple phases, and threads can de- register themselves dynamically. 3. Flexible Registration: Allows dynamic addition and removal of threads. 4. Actions at Phases: Allows actions to be performed at the commencement of each phase. 5. Use Cases: Useful in complex algorithms where the number of threads and phases can change during runtime.

Slide 53

Slide 53 text

@arafkarsh arafkarsh Phaser – Objectives 53 The Java Phaser class is a thread synchronization mechanism that is more flexible than both CyclicBarrier and CountDownLatch. The Phaser ensures that multiple threads can perform a series of actions in sync. Unlike CyclicBarrier, Phaser allows the number of registered parties (threads) to change over time. Objective of Phaser The objective of the Phaser class is to provide a synchronization barrier that allows threads to wait for each other, but with the added flexibility of: 1. Dynamic Registration: You can register or de-register threads dynamically. 2. Phases: You can divide the tasks into multiple phases and synchronize threads at each phase. Use Case Consider a scenario where you have a multiplayer online game with various stages or "phases". Players may join or leave at any stage, and you need to ensure that the stage begins when all players in that stage are ready. Each player can be considered a separate thread, and the game stages as phases.

Slide 54

Slide 54 text

@arafkarsh arafkarsh Phaser – Example 54 • Initialization: A Phaser is initialized with a count of 3, indicating that 3 threads are participating. • All threads must complete each phase before any thread can move on to the next phase, ensuring synchronization between phases. • In microservices, a Phaser could be applicable when you need to orchestrate multiple services or tasks that are part of a workflow. Primarily, when you deal with services that can be dynamically scaled, Phaser provides the ability to handle such complexity with its dynamic registration features. Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 55

Slide 55 text

@arafkarsh arafkarsh Phaser – Example 55 Phase Completion: Threads call arriveAndAwaitAdvance() to signal they have completed the current phase. This call is blocked until all registered threads arrive. Deregistration: Once a thread completes all Stages, it deregisters itself. Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 56

Slide 56 text

@arafkarsh arafkarsh Comparison 56 Feature CyclicBarrier Exchanger Phaser CountDownLatch Functionality Wait for each other Data exchange Multiple phases Wait for events Resettable Yes N/A Yes No Dynamic Registration No No Yes No Actions at Sync Point Yes No Yes No Use Cases Parallel algorithms Data swapping Complex dynamic tasks One-time event wait Complexity Moderate Moderate High Simple

Slide 57

Slide 57 text

@arafkarsh arafkarsh Summary 57 • Cyclic Barrier: Best for scenarios where you have a fixed number of threads that must wait for each other to reach a common point before proceeding. It is beneficial in parallel algorithms like matrix multiplication. • Exchanger: Useful when you need two threads to exchange data at a certain point. This is common in genetic algorithms or task-result reconciliation scenarios. • Phaser: Highly flexible and designed for complex synchronization requirements. It can handle various threads and phases, making it ideal for problems requiring more complex coordination. • CountDownLatch: Suited for scenarios where one or more threads must wait for events to occur. Once all events have occurred, the latch is released. It's simpler but non-resettable.

Slide 58

Slide 58 text

@arafkarsh arafkarsh 2 Thread Pools o Thread Pools and Thread Groups o Future o Completable Future 58

Slide 59

Slide 59 text

@arafkarsh arafkarsh Thread Pools and Thread Groups o Thread Pools o Thread Groups o Thread Pools using Semaphores 59

Slide 60

Slide 60 text

@arafkarsh arafkarsh Thread Pools 60 1. Purpose: Manages a fixed number of threads and reuses them for executing tasks (typically implements Runnable or Callable). 2. Control over Execution: Provides more control over when tasks are executed. 3. Task Queue: Usually has a task queue where tasks wait until a thread becomes available. 4. Resource Management: Better resource management, as the number of threads is fixed and reused, reducing the overhead of thread creation and destruction. 5. Error Handling: It is easier to handle errors and exceptions through features like Future. 6. Shutdown: Provides graceful shutdown capabilities, allowing running tasks to be completed before terminating. 7. Built-in Features: Various built-in policies for task scheduling, thread creation, and termination (e.g., ScheduledThreadPoolExecutor for scheduled tasks). 8. Concurrency Control: Can be used in combination with other concurrency control mechanisms like Semaphore, CountDownLatch, etc.

Slide 61

Slide 61 text

@arafkarsh arafkarsh Thread Pool with Executor Service 61 Advantages 1. Ease of Use: ExecutorService abstracts away many low-level details of thread management. 2. Thread Pooling: Built-in thread pool management. 3. Graceful Shutdown: Provides methods to shut down the pool safely. 4. Task Scheduling: Supports delayed or periodic task execution. 5. Future Support: Can return Future objects to fetch computation results asynchronously. Disadvantages 1. Overhead: Higher-level abstractions may introduce some overhead. 2. Limited Control: More flexible for tasks requiring low-level thread control.

Slide 62

Slide 62 text

@arafkarsh arafkarsh Thread Pool with Executor Service 62 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 63

Slide 63 text

@arafkarsh arafkarsh Thread Groups 63 1. Purpose: Serves as a convenient way to group multiple threads for easier management and control. It doesn't reuse threads. 2. Control over Execution: Limited control over when and how threads within the group are executed. 3. Task Queue: No task queue. Threads are executed as soon as they are started. 4. Resource Management: No inherent resource optimization. Threads are neither pooled nor reused. 5. Error Handling: Provides very minimal support for error handling. 6. Shutdown: It doesn't provide an inherent way to shut down threads gracefully. You have to manage this manually. 7. Built-in Features: Lacks advanced features like scheduling or task prioritization. 8. Concurrency Control: Provides basic synchronization mechanisms but less flexibility than thread pools.

Slide 64

Slide 64 text

@arafkarsh arafkarsh Thread Pool with Thread Groups 64 Advantages 1. Group Operations: Easy to manage a group of threads, like pausing, stopping, or interrupting them at once. 2. Less Overhead: Lower-level than ExecutorService, which can sometimes mean less overhead. 3. Direct Control: More control over the individual threads. Disadvantages 1. Thread Safety: Managing thread life cycles and task submissions can be error-prone. 2. Manual Management: Requires more manual effort for thread pooling and resource management. 3. Deprecation: Some methods of ThreadGroup are deprecated, and it is considered legacy.

Slide 65

Slide 65 text

@arafkarsh arafkarsh Thread Pool with Thread Group 65 ExecutorService is generally recommended for production use due to its robust features, ease of use, and built-in thread pooling capabilities. It provides a cleaner, more maintainable way of handling concurrent tasks. Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 66

Slide 66 text

@arafkarsh arafkarsh Summary 66 Feature Thread Pool Thread Group Purpose Task execution Thread grouping Control High Low Task Queue Yes No Resource Management Optimized Manual Error Handling Advanced Basic Shutdown Graceful Manual Built-in Features Many Few Concurrency Control High Flexibility Basic

Slide 67

Slide 67 text

@arafkarsh arafkarsh Thread Pool / Executor Service / Semaphore 67 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 68

Slide 68 text

@arafkarsh arafkarsh Thread Pool / Executor Service / Semaphore 68 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 69

Slide 69 text

@arafkarsh arafkarsh Asynchronous API o Future o Completable Future 69

Slide 70

Slide 70 text

@arafkarsh arafkarsh Future 70 The Future and CompletableFuture classes in Java provide mechanisms for representing the result of an asynchronous computation. These classes make writing asynchronous, non- blocking, and multi-threaded code easier. Future A Future represents the pending result of an asynchronous computation. It provides methods to check if the computation is complete, to wait for its completion, and to retrieve the result.

Slide 71

Slide 71 text

@arafkarsh arafkarsh Future Example 71 Key Features: 1. Blocking: The get() method is blocking. It waits until the computation is complete, and the result is available. 2. Cancellation: You can cancel a computation using cancel(). 3. Check for Completion: You can check if the computation is complete using isDone(). Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 72

Slide 72 text

@arafkarsh arafkarsh Completable Future 72 CompletableFuture extends the Future to provide a more feature-rich and flexible API for working with asynchronous computations. It enables you to write non-blocking, asynchronous code in a more readable and maintainable manner. Key Features: 1. Non-blocking Operations: Methods like thenApply, thenCompose, and thenCombine allow for non-blocking operations. 2. Combining Multiple Async Computations: You can combine multiple asynchronous computations easily. 3. Exception Handling: It provides methods like exceptionally and handle to deal with exceptions.

Slide 73

Slide 73 text

@arafkarsh arafkarsh Completable Future 73 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 74

Slide 74 text

@arafkarsh arafkarsh Comparison 74 1.Blocking Nature 1. Future: The Future.get() method blocks, meaning it will hold up the thread until the result is available or an exception is thrown. 2. CompletableFuture: Provides a non-blocking, event-driven model for completing the future. You can chain methods like thenApply, thenCompose, etc., to handle results without blocking. 2.Exception Handling 1. Future: Exception handling could be more complex. You'll only know of an exception when you call get(). 2. CompletableFuture: Provides better mechanisms like exceptionally and handle to recover from exceptions. 3.Method Chaining and Composition 1. Future: Does not support method chaining directly. 2. CompletableFuture: Supports method chaining and allows combining multiple asynchronous computations.

Slide 75

Slide 75 text

@arafkarsh arafkarsh Comparison 75 4. Combining Multiple Futures 1. Future: There is no direct way to combine multiple Futures. 2. CompletableFuture: Methods like thenCombine and allOf allow you to combine multiple futures easily. 5. Applicability 1. Future: Suitable for simpler, fire-and-forget asynchronous operations. 2. CompletableFuture: Better suited for complex asynchronous workflow, reactive programming, and combining multiple asynchronous results. 6. Readability 1. Future: As you use external mechanisms for better control flow, the code might become less readable. 2. CompletableFuture: Provides a more readable and maintainable code due to its rich API for composing and combining asynchronous computations.

Slide 76

Slide 76 text

@arafkarsh arafkarsh Completable Future Example 76 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 77

Slide 77 text

@arafkarsh arafkarsh Completable Future Example 77

Slide 78

Slide 78 text

@arafkarsh arafkarsh Comparison – Future / Completable Future 78 Feature Future CompletableFuture Blocking Nature Yes No Exception Handling Basic Advanced Method Chaining No Yes Combine Multiple Futures No Yes Applicability Simple tasks Complex workflows Readability Lower Higher API Complexity Simple Rich and Flexible

Slide 79

Slide 79 text

@arafkarsh arafkarsh Completable Future and Rx Java 79 Completable Future 1. Design Philosophy: Built into the Java standard library, aimed at simplifying asynchronous programming in a future-promise style. 2. Thread Model: Usually utilizes a fixed pool of worker threads, but you can specify custom thread pools. 3. Exception Handling: Provides explicit exception handling using exceptionally() or handle() methods. 4. Chaining Operations: Enables straightforward chaining of asynchronous tasks using methods like thenApply, thenAccept, etc. 5. API: Limited API focused mainly on representing a single future result. It provides methods to combine multiple futures but is less rich and comprehensive than RxJava. 6. Back Pressure: This doesn’t natively support back pressure. 7. Operators: Limited number of operators compared to RxJava. 8. Use-Case: More suitable for simpler use-cases or when dealing with a single asynchronous computation and its resultant data.

Slide 80

Slide 80 text

@arafkarsh arafkarsh Completable Future and Rx Java 80 RxJava Observable 1. Design Philosophy: Implements the Reactive Extensions (Rx) library standards and aims at providing a comprehensive platform for reactive and asynchronous programming. 2. Thread Model: Flexible and allows you to specify schedulers (observeOn, subscribeOn) to control threading behavior more granularly. 3. Exception Handling: This can be done using operators like onErrorResumeNext, onErrorReturn, etc. 4. Chaining Operations: Rich operators like map, filter, zip, concat, etc., for composing asynchronous operations. 5. API: Rich and comprehensive API designed for various use cases, including complex data transformation, filtering, and combination. 6. Back Pressure: Supports back pressure through the Flowable class. 7. Operators: Extensive set of operators for various data manipulations and transformations. 8. Use-Case: Better suited for complex and advanced use cases, especially when dealing with data streams.

Slide 81

Slide 81 text

@arafkarsh arafkarsh Comparison 81 Design Philosophy Future-Promise Reactive Programming Thread Model Fixed or Custom Pool Flexible Schedulers Exception Handling exceptionally() onErrorXXX operators Chaining Limited (thenApply, thenCompose) Extensive (map, filter, etc.) API Richness Limited Rich and Comprehensive Back Pressure No Yes (Flowable) Operators Limited Extensive Best Use-Case Simple Async Tasks Complex Data Streams

Slide 82

Slide 82 text

@arafkarsh arafkarsh 3 Functional Reactive Programming o Architecture & Design Patterns o Building Blocks of Rx Java o Observable and Observer Design Pattern o Examples 82

Slide 83

Slide 83 text

@arafkarsh arafkarsh Functional Reactive Programming 83 Resilient Elastic Message – Driven 1. A responsive, maintainable & Extensible application is the goal. 2. A responsive application is both scalable (Elastic) and resilient. 3. Responsiveness is impossible to achieve without both scalability and resilience. 4. A Message-Driven architecture is the foundation of scalable, resilient, and ultimately responsive systems. Value Means Form Principles What it means? Responsive thus React to users demand Resilient thus React to errors and failures Elastic thus React to load Message-Driven thus React to events and messages Source: http://reactivex.io/ Responsive Maintainable Extensible

Slide 84

Slide 84 text

@arafkarsh arafkarsh Functional Reactive Programming : Result = Decoupling 84 1. Containment of 1. Failures 2. Implementation Details 3. Responsibility 2. Shared Nothing Architecture, Clear Boundaries 3. Single Responsibility Principle

Slide 85

Slide 85 text

@arafkarsh arafkarsh Functional Reactive Programming : Design Patterns 85 85 Single Component Pattern A Component shall do ONLY one thing, But do it in FULL. Single Responsibility Principle By DeMarco : Structured Analysis & System Specification (Yourdon, New York, 1979) Let-It-Crash Pattern Prefer a FULL component restart to complex internal failure handling. Candea & Fox: Crash-Only Software (USENIX HotOS IX, 2003) Popularized by Netflix Chaos Monkey. Erlang Philosophy Saga Pattern Divide long-lived distributed transactions into quick local ones with compensating actions for recovery. Pet Helland: Life Beyond Distributed Transactions CIDR 2007

Slide 86

Slide 86 text

@arafkarsh arafkarsh 4 Building Blocks of RxJava 86 86 Observer Listens for emitted values [ Receiver ] Observable Source of Data Stream [ Sender ] Client Server Request Response Traditional Synchronous Pull Communications 1. The Observer subscribes (listens) to the Observable 2. Observer react to what ever item or sequence of items the Observable emits. 3. Many Observers can subscribe to the same Observable Observer Observable on Next on Completed on Error Time Subscribes Non Blocking Time 1 2

Slide 87

Slide 87 text

@arafkarsh arafkarsh 4 Building Blocks of RxJava 87 Schedulers Operators Content Filtering Time Filtering Transformation Schedulers are used to manage and control concurrency. 1. observeOn: Thread Observable is executed 2. subscribeOn: Thread subscribe is executed Operators that let you Transform, Combine, Manipulate, and work with the sequence of items emitted by Observables 3 4

Slide 88

Slide 88 text

@arafkarsh arafkarsh Observable Design Pattern (Marble Diagram) 1 Building Block 88 • An Observer subscribes to an Observable. • Then that observer reacts to whatever item or sequence of items the Observable emits. Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html | http://rxmarbles.com

Slide 89

Slide 89 text

@arafkarsh arafkarsh Observable / Observer Design Pattern 89 • Allows for Concurrent Operations: the observer does not need to block while waiting for the observable to emit values • Observer waits to receive values when the observable is ready to emit them • Based on push rather than pull 1 & 2 Building Block

Slide 90

Slide 90 text

@arafkarsh arafkarsh What’s missing from GOF Observer Pattern 90 1 Building Block Source:http://reactivex.io/intro.html 1.The ability for the producer to signal to the consumer that there is no more data available (a foreach loop on an Iterable completes and returns normally in such a case; an Observable calls its observer’s onCompleted method) 2.The ability for the producer to signal to the consumer that an error has occurred (an Iterable throws an exception if an error takes place during iteration; an Observable calls its observer’s onError method) 3.Multiple Thread Implementations and hiding those details. 4.Dozens of Operators to handle data.

Slide 91

Slide 91 text

@arafkarsh arafkarsh Compare Iterable Vs. Observable 22 February 2025 91 Observable is the asynchronous / push dual to the synchronous pull Iterable • Composable: Easily chained together or combined • Flexible: Can be used to emit: • A scalar value (network result) • Sequence (items in a list) • Infinite streams (weather sensor) • Free from callback hell: Easy to transform one asynchronous stream into another Observables are: Event Iterable (Pull) Observable (Push) Retrieve Data T next() onNext(T) Discover Error throws Exception onError (Exception) Complete !hasNext() onComplete() 1 Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html

Slide 92

Slide 92 text

@arafkarsh arafkarsh Comparison : Iterable / Streams / Observable 22 February 202592 1 Building Block First Class Visitor (Consumer) Serial Operations Parallel Streams (10x Speed) Still On Next, On Complete and On Error are Serial Operations Completely Asynchronous Operations Java 8 – Blocking Call Java 6 – Blocking Call Rx Java - Freedom Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 93

Slide 93 text

@arafkarsh arafkarsh Observer Contract 93 Methods: • onNext(T) • onError(Throwable T) • onCompleted() onError / onCompleted called precisely once 2 Building Block Source: http://reactivex.io/RxJava/javadoc/index.html?rx/Observable.html X | Time Line

Slide 94

Slide 94 text

@arafkarsh arafkarsh RxJava Scheduler Details 94 Source: http://reactivex.io/documentation/scheduler.html • If you want to introduce multithreading into your cascade of Observable operators, you can do so by instructing those operators (or particular Observables) to operate on particular Schedulers. • By default, an Observable and the chain of operators that you apply to it will do its work, and will notify its observers, on the same thread on which its Subscribe method is called. • The SubscribeOn operator changes this behavior by specifying a different Scheduler on which the Observable should operate. TheObserveOn operator specifies a different Scheduler that the Observable will use to send notifications to its observers. 3 Building Block

Slide 95

Slide 95 text

@arafkarsh arafkarsh RxJava Scheduler Threading Details 22 February 2025 95 Source: http://reactivex.io/documentation/scheduler.html Scheduler Purpose 1 Schedulers.computation ( ) Meant for computational work such as event-loops and callback processing; do not use this scheduler for I/O. (useSchedulers.io( ) instead) The number of threads, by default, is equal to the number of processors 2 Schedulers.from(executor) Uses the specified Executor as a Scheduler 3 Schedulers.immediate ( ) Schedules work to begin immediately in the current thread 4 Schedulers.io ( ) Meant for I/O-bound work such as asynchronous performance of blocking I/O, this scheduler is backed by a thread-pool that will grow as needed; for ordinary computational work, switch to Schedulers.computation( ); Schedulers.io( ) by default is a CachedThreadScheduler, which is something like a new thread scheduler with thread caching 5 Schedulers.newThread ( ) Creates a new thread for each unit of work 6 Schedulers.trampoline ( ) Queues work to begin on the current thread after any already-queued work 3 Building Block

Slide 96

Slide 96 text

@arafkarsh arafkarsh RxJava Operator : Frequently used Content Filtering 1 Observable filter (Func1 Predicate) 2 Observable skip (int num) 3 Observable take (int num) 4 Observable takeLast (int num) 5 Observable elementAt (int index) 6 Observable distinct () 7 Observable distinctUntilChanged () 96 Time Filtering 1 Observable throttleFirst (long duration, TimeUnit unit) 2 Observable throttleLast (long duration, TimeUnit unit) 3 Observable timeout (long duration, TimeUnit unit) Transformation Use 1 Observable map (Func1 func) Transforms Objects 2 Observable flatMap (Func1> func) Transforms an Observable to another Observable 3 Observable cast (Class klass) 4 Observable> groupBy (Func1 keySelector) 4 Building Block Source: http://reactivex.io/

Slide 97

Slide 97 text

@arafkarsh arafkarsh The Problem? How Rx Helps! 97 2 Building Block Apple Basket Fruit Processor Scenario 1. A Basket Full of Apples 2. Fruit Processor capacity (limit) is 3 Apples at a time. The Problem 1. I don’t have time to wait till the Fruit Processor finishes it’s job. 2. I don’t mind having multiple Fruit Processors too. But that still doesn’t solve the problem What I need 1. I want to start the Process and leave. 2. Once the processing is done, then the system should inform me. 3. If something goes wrong, then the system should inform me. Me = the calling program

Slide 98

Slide 98 text

@arafkarsh arafkarsh RxJava : Examples – Handling Fruit Processor 22 February 202598 1 Building Block Completely Asynchronous Operations Rx Java - Freedom 1. Abstract Fruit 2. Fruit (Interface) 3. Apple 4. Orange 5. Grapes 6. Mixed Fruit (Aggregate Root) Entities 1. Fruit Processor (Domain Service) - Observer 2. Fruit Basket Repository 3. Fruit Basket Observable Factory Business Layer Next Section focuses more on Operators and how to handle business logic in Asynchronous world! 1. Rx Java Example : Observable / Observer / Scheduler Implementation 2. Rx Java Example 2 : Merge / Filters (on Weight) / Sort (on Price) Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 99

Slide 99 text

@arafkarsh arafkarsh RxJava : Entities & Repositories 22 February 2025 99 1 Building Block Fruit Interface Abstract Fruit Fruit Repository Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 100

Slide 100 text

@arafkarsh arafkarsh RxJava : Entities 100 1 Building Block Apple Orange Grapes Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 101

Slide 101 text

@arafkarsh arafkarsh Rx 2 Java : Apple Fruit Basket : Observable 101 1 Building Block 1. This function calls the Apple Basket Repository function to load the data. 2. Observable is created using the collection from the data returned by the Repository 3. Subscribe method checks if the Observer is NOT Disposed. 4. If Yes for Each Apple it calls the Observer to do the action = observer.onNext (fruit) 5. Once the process is completed 6. Observable will call the on Complete method in Observer. 7. If an error occurs then Observable will call the on Error method in Observer Fruit Basket Observable Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 102

Slide 102 text

@arafkarsh arafkarsh Rx 2 Java : Fruit Processor : Observer 102 1 Building Block 1. Fruit Processor implements Subscriber (Observer) interface 2. On Next Method Implementation. Main Business logic is done over here. Observable will call on Next and pass the Fruit Object for processing. 3. On Complete Method. Observable will call this method once the processing is done. 4. If Any error occurred then Observable will call on Error method and pass on the Exception. 5. test() implements the Predicate for filtering. Weight is passed as a parameter in Fruit Processor Constructor. Fruit Processor Observer Fruit Processor Handles the Business Logic Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 103

Slide 103 text

@arafkarsh arafkarsh 10 3 Bringing all the pieces together Apple Basket Fruit Processor Observable / Observer / Schedulers / Operators

Slide 104

Slide 104 text

@arafkarsh arafkarsh Rx 2 Java Operator : Merge 3 Streams 104 4 Building Block Objective: Merge Three Data Streams (Apple Fruit Basket, Orange Fruit Basket & Grapes Fruit Basket) into a Single Stream and do the Processing on that new Stream Asynchronously A1 is the Apple Series, O1 is the Orange Series & G1 is the Grapes Series Rx Example 2 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 105

Slide 105 text

@arafkarsh arafkarsh Rx 2 Java Operator : Merge / Filter Streams 105 4 Building Block Objective: From the previous three Merged streams Filter Fruits which weighs more than 50 grams. Rx Example 2 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 106

Slide 106 text

@arafkarsh arafkarsh RxJava Operator : Merge / Filter Streams 106 4 Building Block Objective: From the previous three Merged streams Filter Fruits which weighs more than 50 grams. Rx Example 2 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 107

Slide 107 text

@arafkarsh arafkarsh Rx 2 Java Operator : Merge / Filter / Sort 107 4 Building Block Objective: From the previous three Merged streams Filter Fruits which weighs more than 50 grams and sort on Price (Asc). Rx Example 2 Don’t Use blockgingGet() in Production Code Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 108

Slide 108 text

@arafkarsh arafkarsh Rx 2 Java Operator: Filter / Sort / FlatMap 108 4 Building Block Objective: toSortedList() returns an Observable with a single List containing Fruits. Using FlatMap to Transform Observable to Observable Rx Example 2 Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 109

Slide 109 text

@arafkarsh arafkarsh The Problem? How Rx Helps! 109 2 Building Block Scenario – Three Different Data streams 1. Movie database, Movie Reviews, Movie Trivia 2. Based on the Recommendation Engine combine all the three above and send the final result to end-user / customer. The Problem / Rule 1. No Synchronous Calls allowed What I need 1. Movie Suggestion based on recommendation Engine 2. Filter the suggested movies based on the User filter (Movie Ratings) 3. Once the movies are identified, combine all the other related info and Zip (Movies, Reviews & Trivia) it into a Single Entity (Movie Titles) and send the collection back to the caller.

Slide 110

Slide 110 text

@arafkarsh arafkarsh Movie Example RxJava Operator : Filter / Sort / FlatMap 110 4 Building Block Objective: toSortedList() returns an Observable with a single List containing Movies. Using FlatMap to Transform Observable to Observable Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

Slide 111

Slide 111 text

@arafkarsh arafkarsh RxJava Operator Details 111 4 Building Block Creating Observables Operators that originate new Observables. • Create — create an Observable from scratch by calling observer methods programmatically • Defer — do not create the Observable until the observer subscribes, and create a fresh Observable for each observer • Empty/Never/Throw — create Observables that have very precise and limited behavior • From — convert some other object or data structure into an Observable • Interval — create an Observable that emits a sequence of integers spaced by a particular time interval • Just — convert an object or a set of objects into an Observable that emits that or those objects • Range — create an Observable that emits a range of sequential integers • Repeat — create an Observable that emits a particular item or sequence of items repeatedly • Start — create an Observable that emits the return value of a function • Timer — create an Observable that emits a single item after a given delay Source: http://reactivex.io/

Slide 112

Slide 112 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 112 Source: http://reactivex.io/ Creating Observables Operators that originate new Observables. • Create — create an Observable from scratch by calling observer methods programmatically • Defer — do not create the Observable until the observer subscribes, and create a fresh Observable for each observer • Empty/Never/Throw — create Observables that have very precise and limited behavior • From — convert some other object or data structure into an Observable • Interval — create an Observable that emits a sequence of integers spaced by a particular time interval • Just — convert an object or a set of objects into an Observable that emits that or those objects • Range — create an Observable that emits a range of sequential integers • Repeat — create an Observable that emits a particular item or sequence of items repeatedly • Start — create an Observable that emits the return value of a function • Timer — create an Observable that emits a single item after a given delay 4 Building Block

Slide 113

Slide 113 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 113 Source: http://reactivex.io/ Transforming Observables Operators that transform items that are emitted by an Observable. • Buffer — periodically gather items from an Observable into bundles and emit these bundles rather than emitting the items one at a time • FlatMap — transform the items emitted by an Observable into Observables, then flatten the emissions from those into a single Observable • GroupBy — divide an Observable into a set of Observables that each emit a different group of items from the original Observable, organized by key • Map — transform the items emitted by an Observable by applying a function to each item • Scan — apply a function to each item emitted by an Observable, sequentially, and emit each successive value • Window — periodically subdivide items from an Observable into Observable windows and emit these windows rather than emitting the items one at a time 4 Building Block

Slide 114

Slide 114 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 114 Source: http://reactivex.io/ Filtering Observables Operators that selectively emit items from a source Observable. • Debounce — only emit an item from an Observable if a particular timespan has passed without it emitting another item • Distinct — suppress duplicate items emitted by an Observable • ElementAt — emit only item n emitted by an Observable • Filter — emit only those items from an Observable that pass a predicate test • First — emit only the first item, or the first item that meets a condition, from an Observable • IgnoreElements — do not emit any items from an Observable but mirror its termination notification • Last — emit only the last item emitted by an Observable • Sample — emit the most recent item emitted by an Observable within periodic time intervals • Skip — suppress the first n items emitted by an Observable • SkipLast — suppress the last n items emitted by an Observable • Take — emit only the first n items emitted by an Observable • TakeLast — emit only the last n items emitted by an Observable 4 Building Block

Slide 115

Slide 115 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 115 Source: http://reactivex.io/ Combining Observables Operators that work with multiple source Observables to create a single Observable • And/Then/When — combine sets of items emitted by two or more Observables by means of Pattern and Plan intermediaries • CombineLatest — when an item is emitted by either of two Observables, combine the latest item emitted by each Observable via a specified function and emit items based on the results of this function • Join — combine items emitted by two Observables whenever an item from one Observable is emitted during a time window defined according to an item emitted by the other Observable • Merge — combine multiple Observables into one by merging their emissions • StartWith — emit a specified sequence of items before beginning to emit the items from the source Observable • Switch — convert an Observable that emits Observables into a single Observable that emits the items emitted by the most-recently-emitted of those Observables • Zip — combine the emissions of multiple Observables together via a specified function and emit single items for each combination based on the results of this function 4 Building Block

Slide 116

Slide 116 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 116 Source: http://reactivex.io/ Observable Utility Operators A toolbox of useful Operators for working with Observables • Delay — shift the emissions from an Observable forward in time by a particular amount • Do — register an action to take upon a variety of Observable lifecycle events • Materialize/Dematerialize — represent both the items emitted and the notifications sent as emitted items, or reverse this process • ObserveOn — specify the scheduler on which an observer will observe this Observable • Serialize — force an Observable to make serialized calls and to be well-behaved • Subscribe — operate upon the emissions and notifications from an Observable • SubscribeOn — specify the scheduler an Observable should use when it is subscribed to • TimeInterval — convert an Observable that emits items into one that emits indications of the amount of time elapsed between those emissions • Timeout — mirror the source Observable, but issue an error notification if a particular period of time elapses without any emitted items • Timestamp — attach a timestamp to each item emitted by an Observable • Using — create a disposable resource that has the same lifespan as the Observable 4 Building Block

Slide 117

Slide 117 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 117 Source: http://reactivex.io/ Conditional and Boolean Operators Operators that evaluate one or more Observables or items emitted by Observables • All — determine whether all items emitted by an Observable meet some criteria • Amb — given two or more source Observables, emit all of the items from only the first of these Observables to emit an item • Contains — determine whether an Observable emits a particular item or not • DefaultIfEmpty — emit items from the source Observable, or a default item if the source Observable emits nothing • SequenceEqual — determine whether two Observables emit the same sequence of items • SkipUntil — discard items emitted by an Observable until a second Observable emits an item • SkipWhile — discard items emitted by an Observable until a specified condition becomes false • TakeUntil — discard items emitted by an Observable after a second Observable emits an item or terminates • TakeWhile — discard items emitted by an Observable after a specified condition becomes false 4 Building Block

Slide 118

Slide 118 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 118 Source: http://reactivex.io/ Mathematical and Aggregate Operators Operators that operate on the entire sequence of items emitted by an Observable • Average — calculates the average of numbers emitted by an Observable and emits this average • Concat — emit the emissions from two or more Observables without interleaving them • Count — count the number of items emitted by the source Observable and emit only this value • Max — determine, and emit, the maximum-valued item emitted by an Observable • Min — determine, and emit, the minimum-valued item emitted by an Observable • Reduce — apply a function to each item emitted by an Observable, sequentially, and emit the final value • Sum — calculate the sum of numbers emitted by an Observable and emit this sum Backpressure Operators • backpressure operators — strategies for coping with Observables that produce items more rapidly than their observers consume them 4 Building Block

Slide 119

Slide 119 text

@arafkarsh arafkarsh Rx 2 Java Operator Details 119 Source: http://reactivex.io/ Connectable Observable Operators Specialty Observables that have more precisely-controlled subscription dynamics • Connect — instruct a connectable Observable to begin emitting items to its subscribers • Publish — convert an ordinary Observable into a connectable Observable • RefCount — make a Connectable Observable behave like an ordinary Observable • Replay — ensure that all observers see the same sequence of emitted items, even if they subscribe after the Observable has begun emitting items Operators to Convert Observables • To — convert an Observable into another object or data structure Error Handling Operators Operators that help to recover from error notifications from an Observable • Catch — recover from an onError notification by continuing the sequence without error • Retry — if a source Observable sends an onError notification, re-subscribe to it in the hopes that it will complete without error 4 Building Block

Slide 120

Slide 120 text

@arafkarsh arafkarsh 2/22/2025 120 • onCompleted became onComplete— without the trailing d • Func1 became Function • Func2 became BiFunction • CompositeSubscription became CompositeDisposable • limit operator has been removed. Use take in RxJava 2 Rx Java 1 to Rx Java 2 Migration

Slide 121

Slide 121 text

@arafkarsh arafkarsh 2/22/2025 121 Rx Java 1 to Rx Java 2 Migration Object Method Call import rx.Observable; Observable.operator Observer call(Observer) import rx.*; Observer void onCompleted Subscriber implements Observer Import rx.Observable; Observerable.onSubscribe void call(Observer) Observer > Subscriber onNext() onCompleted() onError() - isUnSubscribed() Object Method Call import io.reactivex.*; ObservableOperator Subscriber apply(Subscriber) import io.reactivex.*; Observer void onComplete No Subscriber Class in v2.0 Import io.reactivex.* ObservableOnSubscriber Void subscribe(ObservableEmitter) throws Exception Emitter > ObservableEmitter onNext() onComplete() onError() - IsDisposed() Rx Java 1.0 Package = rx.* Rx Java 2.0 Package = io.reactivex.* http://reactivex.io/RxJava/1.x/javadoc/ http://reactivex.io/RxJava/2.x/javadoc/ This is not a comprehensive list, but a most used list.

Slide 122

Slide 122 text

@arafkarsh arafkarsh 2/22/2025 122 Rx Java 1 to Rx Java 2 Migration Object Method Call import rx.functions.*; Func1 T call(T) import rx.Observable; Observable filter(Func1) Observable Observable first() Observable flatMap(Func1) void forEach(Action1) Observable from(Future) Observable from(Iterable) Observable from(Array) Observable(GroupedObservable) groubBy(Func1) Observable groupJoin(Observable) Object Method Call io.reactivex.functions.*; Function1 T apply(T) import io.reactivex.*; Observable filter(Predicate) Observable Single first() Observable flatMap(Function) Disposable forEach(Consumer) Observable fromFuture(Future) Observable fromIterable(Iterable) Observable fromArray(Array) Observable(GroupedObservable) groubBy(Function) Observable groupJoin(ObservableSource) Rx Java 1.0 Package = rx.* Rx Java 2.0 Package = io.reactivex.* http://reactivex.io/RxJava/1.x/javadoc/ http://reactivex.io/RxJava/2.x/javadoc/ This is not a comprehensive list, but a most used list.

Slide 123

Slide 123 text

@arafkarsh arafkarsh 2/22/2025 123 Rx Java 1 to Rx Java 2 Migration Object Method Call import rx.Observable; Observable Observable Join(Observable, Func1) Observable all(Func1) Observable amb(Observable….) asObservable() Observable collect(Func0, Action2) Observable contact(Observable) Observable concatMap(Func1) Observable contains() Object Method Call import io.reactivex.*; Observable Observable Join(ObservableSource, Function) Single all(Predicate) Observable amb(Iterable) Single collect(java.util.concurrent.Callable) Observable concat(ObservableSource) Observable concatMap(Function) Single contains() Rx Java 1.0 Package = rx.* Rx Java 2.0 Package = io.reactivex.* http://reactivex.io/RxJava/1.x/javadoc/ http://reactivex.io/RxJava/2.x/javadoc/ This is not a comprehensive list, but a most used list.

Slide 124

Slide 124 text

@arafkarsh arafkarsh 2/22/2025 124 Rx Java 1 to Rx Java 2 Migration Object Method Call import rx.Observable; Observable countLong() Observable static Observable create(Action1, Emitter.backpressure) static Observable create(-----) Observable debounce(Func1) Observable distinct(Func1) Observable exists(Func1) Observable first() Object Method Call import io.reactivex.*; Observable static Observable create(ObservableOnSubscriber) Observable debounce(Function) Observable distinct(Function) Single first(T) Rx Java 1.0 Package = rx.* Rx Java 2.0 Package = io.reactivex.* http://reactivex.io/RxJava/1.x/javadoc/ http://reactivex.io/RxJava/2.x/javadoc/ This is not a comprehensive list, but a most used list.

Slide 125

Slide 125 text

@arafkarsh arafkarsh 4 Spring WebFlux o SpringBoot MVC o Spring MVC and WebFlux o Servlet and Reactive Life Cycle o Comparison 125

Slide 126

Slide 126 text

@arafkarsh arafkarsh SpringBoot WebFlux 126

Slide 127

Slide 127 text

@arafkarsh arafkarsh Springboot MVC 127 Spring Boot MVC is an extension of the Spring framework that simplifies the development of web applications by using the Model-View-Controller (MVC) design pattern. It provides features like dependency injection, data binding, and application-layer frameworks integrated through the Spring framework. Key Features • Annotation-based Configuration: Simplifies the setup of the application. • Built-in Tomcat, Jetty, or Undertow Servers: No need to deploy WAR files. • Data Binding: Maps client-side values to server-side models. • Thymeleaf, JSP, and More: Allows multiple view technologies.

Slide 128

Slide 128 text

@arafkarsh arafkarsh Springboot MVC: How it works? 128 1. Controller: Handles incoming requests. Annotated with @Controller. 2. View: The user interface is usually written in Thymeleaf, JSP, or Angular / React-based frontends. 3. Model: Represents application data. Populated by the controller and accessed by the view. Use Cases • Ideal for form-based applications and template- based HTML views. • Suitable for applications that require a tightly integrated backend, where there is direct data manipulation.

Slide 129

Slide 129 text

@arafkarsh arafkarsh SpringBoot MVC 129 Controller @RestController Service @Service Repository @Repository Model @Entity Data Store Firewall Users DTO @Autowired Service … @Autowired Repository … Dependency Injection Form of IoC

Slide 130

Slide 130 text

@arafkarsh arafkarsh SpringBoot MVC 130 Controller @RestController Service @Service Repository @Repository Model @Entity Data Store Firewall Users DTO @Autowired Service … @Autowired Repository … Dependency Injection Form of IoC Dispatcher Servlet Handler Mapping

Slide 131

Slide 131 text

@arafkarsh arafkarsh Springboot WebFlux 131 Spring Boot WebFlux is a reactive-stack web framework, part of the Spring 5+ ecosystem, fully non-blocking, and supports Reactive stream back pressure. It's designed to handle many simultaneous, high-latency I/O operations with minimal threads. Key Features • Reactive Programming: Utilizes Project Reactor for reactive programming. • Back-Pressure: Manages resource consumption rates. • Non-blocking: Doesn't block threads, leading to better resource utilization.

Slide 132

Slide 132 text

@arafkarsh arafkarsh Springboot WebFlux: How it works? 132 1. Handler: Similar to controllers but designed for reactive programming. Annotated with @RestController. 2. Router: Maps requests to handlers. Can be Java or Kotlin. 3. Reactive Streams: Utilizes publishers (Flux, Mono) for data emission. Use Cases • Suited for applications that require a high degree of scalability. • Suitable for real-time event processing, like chat applications or real-time notifications.

Slide 133

Slide 133 text

@arafkarsh arafkarsh Springboot WebFlux: How it works? 133 Instead of @RestController • .route(RequestPredicates.GET("/hello"): Specifies that the route is for GET requests with the path /hello. • .and(RequestPredicates.accept(MediaType.TEXT_PLAIN )): Adds another condition that the accepted media type should be text/plain. • myHandler::sayHello: Specifies that the sayHello method from MyHandler will handle the request. • RouterFunction: Responsible for providing routing information. It tells the application which handler function needs to be executed for a particular URL pattern. • ServerResponse and ServerRequest: These are abstractions over HTTP request and response models. They offer a more functional way to deal with HTTP requests and responses. • RequestPredicates: These are used to match HTTP requests based on various conditions like HTTP method, URL, headers, etc. • Mono and Flux: These are Reactor types used for asynchronous programming. In the above example, Mono is used, which means zero or one element could be returned.

Slide 134

Slide 134 text

@arafkarsh arafkarsh WebFlux Internals 134 The responsibility of handling and routing requests in Spring WebFlux is mainly undertaken by several different components working together: 1. HttpHandler: This is the basic interface that any reactive server must implement to handle HTTP requests. It's similar to the Servlet API's Servlet interface. 2. WebHandler: This is a specialization of HttpHandler used by Spring's WebHttpHandlerBuilder and provides a convenient way to build a composite HttpHandler with several customizations and configurations. 3. RouterFunction: This function takes a request and returns a HandlerFunction wrapped in a Mono. It's used for functional-style routing, an alternative to the annotation- based controller model. 4. HandlerFunction: This function handles a request and produces a response. It's similar to a controller method in Spring MVC. 5. WebFilter: This is similar to a Filter in the Servlet API. It's a function that can intercept and modify incoming requests and outgoing responses.

Slide 135

Slide 135 text

@arafkarsh arafkarsh Spring MVC Vs WebFlux 135 SpringBoot MVC SpringBoot WebFlux Source: Getting started with Spring WebFlux

Slide 136

Slide 136 text

@arafkarsh arafkarsh Spring MVC vs. WebFlux 136 Aspect Spring Boot MVC Spring Boot WebFlux Programming Model Synchronous Asynchronous Throughput Lower Higher Complexity Lower Higher Learning Curve Easier Steeper Ecosystem Mature Emerging

Slide 137

Slide 137 text

@arafkarsh arafkarsh Servlet and Reactive – Life Cycle 137 1 A request is made by the client. A request is made by the client. 2 The Servlet container creates HttpServletRequest and HttpServletResponse objects. The Reactor Netty (default server used by WebFlux) creates ServerRequest and ServerResponse objects. 3 A separate thread is assigned to this request- response pair and the control is passed to the appropriate Servlet The control is passed to the appropriate handler function without assigning a separate thread to this request- response pair. 4 The Servlet processes the request (which may involve calling various services, accessing a database, etc.), populates the HttpServletResponse object and returns control back to the Servlet container. The handler function processes the request in a non- blocking manner. This may involve calling various services, accessing a database, etc. While the process is waiting for the results (for instance, from a database), the thread is not blocked and can be used to handle other requests. 5 The Servlet container sends the response back to the client and the thread is released. Once the results are available, they are populated in the ServerResponse object and returned back. 6 The Reactor Netty sends the response back to the client.

Slide 138

Slide 138 text

@arafkarsh arafkarsh Comparison 138 1 Concurrency Model: The Servlet API uses a blocking I/O model, meaning each request is handled by a dedicated thread until it's completed. Reactive Streams, on the other hand, employ a non-blocking I/O model where threads can handle other requests when idle. 2 Resource Utilization With Servlet API, under heavy load, you might end up exhausting all system resources since each request demands a separate thread. Reactive Streams are more efficient in resource utilization as they allow more requests to be handled concurrently using fewer threads. 3 Backpressure The Servlet API does not have a built-in mechanism for back pressure. Reactive Streams allow for backpressure, meaning the consumer can control how much data it can handle, preventing it from being overwhelmed. 4 API Design: The Servlet API is based on a synchronous and imperative style of programming, which is easy to understand but can lead to callback hell in complex applications. Reactive Streams (like Spring WebFlux) support a declarative style of programming using Functional Programming principles, leading to cleaner and more maintainable code.

Slide 139

Slide 139 text

@arafkarsh arafkarsh Demo and Code Review o SpringBoot WebFlux o Controllers, Routers, Services, Repositories o Exception Handling o Web Filters 139 Spring WebFlux Reactive Programming: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 140

Slide 140 text

@arafkarsh arafkarsh RestController – Exception from Service 140 Success Message Failure Message http://localhost:9092/ms-webflux/api/v1/country/id/356 Reactive Controller Returning a Mono with Standard Response. Exception from the Service is propagated to the Global Exception Handler. Standard Response 1. Time 2. Success Status 3. Error Code 4. Message 5. Payload Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 141

Slide 141 text

@arafkarsh arafkarsh RestController – Exception from Controller 141 http://localhost:9092/ms-webflux/api/v1/country/code/ARG Reactive Controller Returning a Mono with Standard Response. Rest Controller is throwing the Business Service Exception if the Result is Empty. Standard Response 1. Time 2. Success Status 3. Error Code 4. Message 5. Payload Success Message Failure Message Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 142

Slide 142 text

@arafkarsh arafkarsh Router (instead of Rest Controller) 142 http://localhost:9092/ms-webflux/api/v1/cart/customer/123 Cart Handler Router In Spring WebFlux, a router function is generally expected to return a Mono. This is not because of any limitation in returning a Flux but because the router function is supposed to produce a single ServerResponse object to handle the HTTP request. The Mono encapsulates the HTTP response, including the status code, headers, and body. If you want the body of the HTTP response to contain a stream of values (e.g., a JSON array), then that stream should be a Flux and wrapped inside the ServerResponse object. Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 143

Slide 143 text

@arafkarsh arafkarsh Router / Handlers – Exceptions 143 Success Message Failure Message In Spring WebFlux, the distinction between routers and handlers is designed to separate concerns. Handlers are responsible for business logic, and it is there that exceptions would naturally occur. They handle the request and generate the response, so they handle all the intricacies that may include errors or exceptions. On the other hand, Routers are concerned solely with routing: they determine which handler should handle a given request based on URL patterns, HTTP methods, and other request criteria. Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 144

Slide 144 text

@arafkarsh arafkarsh Service Layer 144 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 145

Slide 145 text

@arafkarsh arafkarsh Repository Layer 145 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 146

Slide 146 text

@arafkarsh arafkarsh Streaming Data o Server-Side Events in WebFlux o Web Sockets 146

Slide 147

Slide 147 text

@arafkarsh arafkarsh Server-Side Streaming Events o Uni-Directional 147

Slide 148

Slide 148 text

@arafkarsh arafkarsh Server-Side Events – Streaming Data 148 3 Seconds Delayed & Random Errors Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 149

Slide 149 text

@arafkarsh arafkarsh Server-Side Events: Result 149

Slide 150

Slide 150 text

@arafkarsh arafkarsh How Server-Side Events (SSE) Work? 150 1. Initiation: The client (a web application or a mobile app) requests an HTTP GET to a specific URL on the server. The request asks for a particular MIME type, usually text/event-stream. 2. Server Response: The server accepts the request and opens a stream, keeping the connection open. The server can then push data to the client whenever it has new information to share. 3. Data Format: The data is sent as plain text in a specific format that the client can interpret. Typically, each message is separated by a pair of newline characters. 4. Client Handling: On the client side, the EventSource JavaScript API or corresponding mobile libraries handle incoming data. Event listeners can be attached to process the data. 5. Unidirectional: SSE is unidirectional; the server sends data to the client, but the client cannot send data back through the same connection. If the client needs to send data to the server, it would use regular AJAX requests or other mechanisms.

Slide 151

Slide 151 text

@arafkarsh arafkarsh Server-Side Events – Streaming Data 151 o When streaming data using protocols like Server-Sent Events (as you are doing with MediaType.TEXT_EVENT_STREAM_VALUE), the HTTP status code is sent only once at the beginning of the connection. The individual items in the stream do not contain HTTP status codes. o The client initially makes a request and receives an HTTP status code that indicates the success or failure of that initial request. If the initial request is successful (typically returning a 200 OK status), the server will keep the connection open and stream data as a series of "events." o Each Event will NOT have its own HTTP status code.

Slide 152

Slide 152 text

@arafkarsh arafkarsh WebSocket o Multi-Directional o Plain Text and Binary Data 152

Slide 153

Slide 153 text

@arafkarsh arafkarsh Web Socket Configuration 153 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 154

Slide 154 text

@arafkarsh arafkarsh Web Socket – Streaming Data 154 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc WebFlux application using WebSockets, the Flux doesn't need an explicit .subscribe() method because it is subscribed to by the framework itself when you return it from the handle method. Life-cycle Management: WebFlux handles the subscription and unsubscription automatically when the WebSocket session starts and ends.. This differs from a standalone application, where you would need to call subscribe to start the data flow explicitly.

Slide 155

Slide 155 text

@arafkarsh arafkarsh Web Socket Result 155 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 156

Slide 156 text

@arafkarsh arafkarsh How Web Sockets work? 156 1. Initiation: A standard HTTP request is upgraded using the Upgrade header to a WebSocket connection. 2. Bidirectional: Unlike SSE, WebSockets provide a full-duplex communication channel. Both client and server can send data to each other at any time. 3. Data Format: The data can be sent as plain text or binary. 4. Client Handling: The WebSocket API in JavaScript or equivalent libraries in mobile apps are used to handle data. 5. More Features: WebSockets support more features like framing, ping/pong control messages, etc.

Slide 157

Slide 157 text

@arafkarsh arafkarsh Web Sockets 157 WebSocket protocol provides full-duplex communication channels over a single, long-lived TCP connection. It is designed to be implemented in client-side web browsers and server-side applications to enable real-time applications like chat, notifications, and collaborative editing. Here are some key features: Framing: WebSocket data is transmitted in frames, each consisting of a header and payload. The header contains metadata about the frame, like opcode (defines the frame type), a payload length indicator, and optional masking information. This structure allows more efficient data transfer and better control over the transmission. • Continuation Frame: To send payloads that exceed the frame size, continuation frames can be used. A message is fragmented into multiple frames, and continuation frames carry the payload in ordered parts. • Text and Binary Frame: WebSocket supports text and binary data frames. The opcode in the frame header differentiates between the two. • Control Frames: These are frames with opcodes that dictate control messages for connection management, such as close, ping, and pong frames.

Slide 158

Slide 158 text

@arafkarsh arafkarsh Web Sockets 158 Ping/Pong Control Messages: Ping/Pong frames are control frames that serve as "heartbeats" for the connection. • Ping: When a server or client sends a ping frame, it asks for a quick response to confirm that the other end is still available. The ping frame can contain optional application data. • Pong: A pong frame is sent in response to a ping frame, ideally containing the same data as the ping frame. This mechanism allows either end to check the "liveness" of the connection. Connection Close: WebSocket has a closing handshake that allows the client and server to close the connection gracefully. The client or server initiates a “Close” control frame, and the receiving end is expected to reply with another "Close" frame. Once the closing handshake is completed, the connection is terminated.

Slide 159

Slide 159 text

@arafkarsh arafkarsh Web Sockets 159 Masking: In client-to-server communication, WebSocket protocol mandates the data to be masked for security reasons. This is intended to prevent specific security vulnerabilities related to "cache poisoning" in network infrastructure. Multiplexing: Although not part of the initial WebSocket standard, there's an extension that allows for multiplexing—multiple logical channels over a single WebSocket connection. This is useful for more complex applications that require separate channels for different types of data. Compression: WebSocket allows for payload compression through the per-message compression extension. This helps reduce the amount of data transferred over the network.

Slide 160

Slide 160 text

@arafkarsh arafkarsh Filters and Exception Handling o Web Filters o Exception Handling o Standard Response 160

Slide 161

Slide 161 text

@arafkarsh arafkarsh Web Filter 161 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 162

Slide 162 text

@arafkarsh arafkarsh Exception Handling 162 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 163

Slide 163 text

@arafkarsh arafkarsh Exception Handling 163 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 164

Slide 164 text

@arafkarsh arafkarsh Debugging Reactive Programming o Log Messages o Checkpoints o doOn… Hooks 164

Slide 165

Slide 165 text

@arafkarsh arafkarsh Debugging Options 165 1. Reactor Debug Agent: This helps to track the original stack trace elements and gives more meaningful information about errors. This is initialized at the start of the application with ReactorDebugAgent.init(). 2. BlockHound: This Java agent detects blocking calls from non-blocking threads and throws an exception. While not exclusively a debugging tool for reactive pipelines, it's beneficial for maintaining the integrity of your reactive system. It helps you spot where you inadvertently introduce blocking behavior in your code. 3. Custom doOn Operators: Reactor provides a host of doOn methods like doOnNext, doOnError, doOnTerminate, etc., where you can insert custom logic, such as logging or incrementing metrics counters. 4. Using Hooks: Reactor provides an API to register custom logic that will be executed on certain events like onNext, onError, onSubscribe, etc., using the Hooks class. 5. Testing: Frameworks like StepVerifier allow you to write unit tests for your reactive pipelines. This can be very helpful for debugging and isolating issues in a controlled environment.

Slide 166

Slide 166 text

@arafkarsh arafkarsh Debugging Options 166 6. Profiler Tools: Profiling can be helpful in identifying resource leaks or performance bottlenecks in your reactive pipelines. 7. R2DBC Debug Logging: If you use R2DBC for reactive database access, enabling debug logging can provide insights into SQL queries and database transactions. 8. Metrics: Libraries like Micrometer can provide runtime metrics which can be helpful in debugging performance and behaviour issues. 9. Distributed Tracing: Tools like Zipkin or Jaeger can be used to trace the request flow across various microservices, which can be helpful in debugging issues in a more extensive, distributed system. 10. Visual Debugging: Some IDEs offer visual tools to debug reactive streams, which can be more intuitive for some developers.

Slide 167

Slide 167 text

@arafkarsh arafkarsh Checkpoints o Logs and Checkpoints o Conditional Checkpoints 167

Slide 168

Slide 168 text

@arafkarsh arafkarsh Checkpoint – Stack Traces & Logging 168 The concept of "Checkpoints" in Project Reactor is a debugging feature that helps you to identify issues in a reactive stream. A checkpoint acts like a marker or a tag in the reactive chain, capturing the state and context of the stream at that specific point. When an error occurs downstream, these checkpoints are included in the stack trace, making it easier to debug issues. Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 169

Slide 169 text

@arafkarsh arafkarsh Checkpoint – Stack Traces & Logging 169 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 170

Slide 170 text

@arafkarsh arafkarsh Checkpoint – Stack Traces & Logging 170 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 171

Slide 171 text

@arafkarsh arafkarsh Reactive Request and Error 171 http://localhost:9092/ms-webflux/api/v1/country/code/FRA1

Slide 172

Slide 172 text

@arafkarsh arafkarsh Checkpoint - Stack Traces 172 Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

Slide 173

Slide 173 text

@arafkarsh arafkarsh Conditional Checkpoints 173 Checkpoints can be enabled conditionally based on a property flag. Using ”transform,” the conditional flag can be checked and enable checkpoints.

Slide 174

Slide 174 text

@arafkarsh arafkarsh Conditional Checkpoints 174 Stack Trace with Checkpoints disabled and logs removed. Stack Trace with Checkpoints enabled and logs removed.

Slide 175

Slide 175 text

@arafkarsh arafkarsh doOn…. o doOnNext o doOnError o doOnComplete o doOnTerminate o doOnEach 175

Slide 176

Slide 176 text

@arafkarsh arafkarsh doOnNext – More Logs 176

Slide 177

Slide 177 text

@arafkarsh arafkarsh doOnError – More Logs 177

Slide 178

Slide 178 text

@arafkarsh arafkarsh doOnComplete – More Logs 178

Slide 179

Slide 179 text

@arafkarsh arafkarsh doOnTerminate – More Logs 179

Slide 180

Slide 180 text

@arafkarsh arafkarsh doOnEach – More Logs 180

Slide 181

Slide 181 text

@arafkarsh arafkarsh Hooks 181

Slide 182

Slide 182 text

@arafkarsh arafkarsh Hooks 182

Slide 183

Slide 183 text

@arafkarsh arafkarsh 183 Design Patterns are solutions to general problems that software developers faced during software development. Design Patterns

Slide 184

Slide 184 text

@arafkarsh arafkarsh 184 Thank you DREAM EMPOWER AUTOMATE MOTIVATE India: +91.999.545.8627 https://arafkarsh.medium.com/ https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.slideshare.net/arafkarsh http://www.arafkarsh.com/ @arafkarsh arafkarsh LinkedIn arafkarsh.com Medium.com Speakerdeck.com

Slide 185

Slide 185 text

@arafkarsh arafkarsh 185 Slides: https://speakerdeck.com/arafkarsh Blogs https://arafkarsh.medium.com/ Web: https://arafkarsh.com/ Source: https://github.com/arafkarsh

Slide 186

Slide 186 text

@arafkarsh arafkarsh 186 Slides: https://speakerdeck.com/arafkarsh

Slide 187

Slide 187 text

@arafkarsh arafkarsh References 187 1. July 15, 2015 – Agile is Dead : GoTo 2015 By Dave Thomas 2. Apr 7, 2016 - Agile Project Management with Kanban | Eric Brechner | Talks at Google 3. Sep 27, 2017 - Scrum vs Kanban - Two Agile Teams Go Head-to-Head 4. Feb 17, 2019 - Lean vs Agile vs Design Thinking 5. Dec 17, 2020 - Scrum vs Kanban | Differences & Similarities Between Scrum & Kanban 6. Feb 24, 2021 - Agile Methodology Tutorial for Beginners | Jira Tutorial | Agile Methodology Explained. Agile Methodologies

Slide 188

Slide 188 text

@arafkarsh arafkarsh References 188 1. Vmware: What is Cloud Architecture? 2. Redhat: What is Cloud Architecture? 3. Cloud Computing Architecture 4. Cloud Adoption Essentials: 5. Google: Hybrid and Multi Cloud 6. IBM: Hybrid Cloud Architecture Intro 7. IBM: Hybrid Cloud Architecture: Part 1 8. IBM: Hybrid Cloud Architecture: Part 2 9. Cloud Computing Basics: IaaS, PaaS, SaaS 1. IBM: IaaS Explained 2. IBM: PaaS Explained 3. IBM: SaaS Explained 4. IBM: FaaS Explained 5. IBM: What is Hypervisor? Cloud Architecture

Slide 189

Slide 189 text

@arafkarsh arafkarsh References 189 Microservices 1. Microservices Definition by Martin Fowler 2. When to use Microservices By Martin Fowler 3. GoTo: Sep 3, 2020: When to use Microservices By Martin Fowler 4. GoTo: Feb 26, 2020: Monolith Decomposition Pattern 5. Thought Works: Microservices in a Nutshell 6. Microservices Prerequisites 7. What do you mean by Event Driven? 8. Understanding Event Driven Design Patterns for Microservices

Slide 190

Slide 190 text

@arafkarsh arafkarsh References – Microservices – Videos 190 1. Martin Fowler – Micro Services : https://www.youtube.com/watch?v=2yko4TbC8cI&feature=youtu.be&t=15m53s 2. GOTO 2016 – Microservices at NetFlix Scale: Principles, Tradeoffs & Lessons Learned. By R Meshenberg 3. Mastering Chaos – A NetFlix Guide to Microservices. By Josh Evans 4. GOTO 2015 – Challenges Implementing Micro Services By Fred George 5. GOTO 2016 – From Monolith to Microservices at Zalando. By Rodrigue Scaefer 6. GOTO 2015 – Microservices @ Spotify. By Kevin Goldsmith 7. Modelling Microservices @ Spotify : https://www.youtube.com/watch?v=7XDA044tl8k 8. GOTO 2015 – DDD & Microservices: At last, Some Boundaries By Eric Evans 9. GOTO 2016 – What I wish I had known before Scaling Uber to 1000 Services. By Matt Ranney 10. DDD Europe – Tackling Complexity in the Heart of Software By Eric Evans, April 11, 2016 11. AWS re:Invent 2016 – From Monolithic to Microservices: Evolving Architecture Patterns. By Emerson L, Gilt D. Chiles 12. AWS 2017 – An overview of designing Microservices based Applications on AWS. By Peter Dalbhanjan 13. GOTO Jun, 2017 – Effective Microservices in a Data Centric World. By Randy Shoup. 14. GOTO July, 2017 – The Seven (more) Deadly Sins of Microservices. By Daniel Bryant 15. Sept, 2017 – Airbnb, From Monolith to Microservices: How to scale your Architecture. By Melanie Cubula 16. GOTO Sept, 2017 – Rethinking Microservices with Stateful Streams. By Ben Stopford. 17. GOTO 2017 – Microservices without Servers. By Glynn Bird.

Slide 191

Slide 191 text

@arafkarsh arafkarsh References 191 Domain Driven Design 1. Oct 27, 2012 What I have learned about DDD Since the book. By Eric Evans 2. Mar 19, 2013 Domain Driven Design By Eric Evans 3. Jun 02, 2015 Applied DDD in Java EE 7 and Open Source World 4. Aug 23, 2016 Domain Driven Design the Good Parts By Jimmy Bogard 5. Sep 22, 2016 GOTO 2015 – DDD & REST Domain Driven API’s for the Web. By Oliver Gierke 6. Jan 24, 2017 Spring Developer – Developing Micro Services with Aggregates. By Chris Richardson 7. May 17. 2017 DEVOXX – The Art of Discovering Bounded Contexts. By Nick Tune 8. Dec 21, 2019 What is DDD - Eric Evans - DDD Europe 2019. By Eric Evans 9. Oct 2, 2020 - Bounded Contexts - Eric Evans - DDD Europe 2020. By. Eric Evans 10. Oct 2, 2020 - DDD By Example - Paul Rayner - DDD Europe 2020. By Paul Rayner

Slide 192

Slide 192 text

@arafkarsh arafkarsh References 192 Event Sourcing and CQRS 1. IBM: Event Driven Architecture – Mar 21, 2021 2. Martin Fowler: Event Driven Architecture – GOTO 2017 3. Greg Young: A Decade of DDD, Event Sourcing & CQRS – April 11, 2016 4. Nov 13, 2014 GOTO 2014 – Event Sourcing. By Greg Young 5. Mar 22, 2016 Building Micro Services with Event Sourcing and CQRS 6. Apr 15, 2016 YOW! Nights – Event Sourcing. By Martin Fowler 7. May 08, 2017 When Micro Services Meet Event Sourcing. By Vinicius Gomes

Slide 193

Slide 193 text

@arafkarsh arafkarsh References 193 Kafka 1. Understanding Kafka 2. Understanding RabbitMQ 3. IBM: Apache Kafka – Sept 18, 2020 4. Confluent: Apache Kafka Fundamentals – April 25, 2020 5. Confluent: How Kafka Works – Aug 25, 2020 6. Confluent: How to integrate Kafka into your environment – Aug 25, 2020 7. Kafka Streams – Sept 4, 2021 8. Kafka: Processing Streaming Data with KSQL – Jul 16, 2018 9. Kafka: Processing Streaming Data with KSQL – Nov 28, 2019

Slide 194

Slide 194 text

@arafkarsh arafkarsh References 194 Databases: Big Data / Cloud Databases 1. Google: How to Choose the right database? 2. AWS: Choosing the right Database 3. IBM: NoSQL Vs. SQL 4. A Guide to NoSQL Databases 5. How does NoSQL Databases Work? 6. What is Better? SQL or NoSQL? 7. What is DBaaS? 8. NoSQL Concepts 9. Key Value Databases 10. Document Databases 11. Jun 29, 2012 – Google I/O 2012 - SQL vs NoSQL: Battle of the Backends 12. Feb 19, 2013 - Introduction to NoSQL • Martin Fowler • GOTO 2012 13. Jul 25, 2018 - SQL vs NoSQL or MySQL vs MongoDB 14. Oct 30, 2020 - Column vs Row Oriented Databases Explained 15. Dec 9, 2020 - How do NoSQL databases work? Simply Explained! 1. Graph Databases 2. Column Databases 3. Row Vs. Column Oriented Databases 4. Database Indexing Explained 5. MongoDB Indexing 6. AWS: DynamoDB Global Indexing 7. AWS: DynamoDB Local Indexing 8. Google Cloud Spanner 9. AWS: DynamoDB Design Patterns 10. Cloud Provider Database Comparisons 11. CockroachDB: When to use a Cloud DB?

Slide 195

Slide 195 text

@arafkarsh arafkarsh References 195 Docker / Kubernetes / Istio 1. IBM: Virtual Machines and Containers 2. IBM: What is a Hypervisor? 3. IBM: Docker Vs. Kubernetes 4. IBM: Containerization Explained 5. IBM: Kubernetes Explained 6. IBM: Kubernetes Ingress in 5 Minutes 7. Microsoft: How Service Mesh works in Kubernetes 8. IBM: Istio Service Mesh Explained 9. IBM: Kubernetes and OpenShift 10. IBM: Kubernetes Operators 11. 10 Consideration for Kubernetes Deployments Istio – Metrics 1. Istio – Metrics 2. Monitoring Istio Mesh with Grafana 3. Visualize your Istio Service Mesh 4. Security and Monitoring with Istio 5. Observing Services using Prometheus, Grafana, Kiali 6. Istio Cookbook: Kiali Recipe 7. Kubernetes: Open Telemetry 8. Open Telemetry 9. How Prometheus works 10. IBM: Observability vs. Monitoring

Slide 196

Slide 196 text

@arafkarsh arafkarsh References 196 1. Feb 6, 2020 – An introduction to TDD 2. Aug 14, 2019 – Component Software Testing 3. May 30, 2020 – What is Component Testing? 4. Apr 23, 2013 – Component Test By Martin Fowler 5. Jan 12, 2011 – Contract Testing By Martin Fowler 6. Jan 16, 2018 – Integration Testing By Martin Fowler 7. Testing Strategies in Microservices Architecture 8. Practical Test Pyramid By Ham Vocke Testing – TDD / BDD

Slide 197

Slide 197 text

@arafkarsh arafkarsh 197 1. Simoorg : LinkedIn’s own failure inducer framework. It was designed to be easy to extend and most of the important components are plug‐ gable. 2. Pumba : A chaos testing and network emulation tool for Docker. 3. Chaos Lemur : Self-hostable application to randomly destroy virtual machines in a BOSH- managed environment, as an aid to resilience testing of high-availability systems. 4. Chaos Lambda : Randomly terminate AWS ASG instances during business hours. 5. Blockade : Docker-based utility for testing network failures and partitions in distributed applications. 6. Chaos-http-proxy : Introduces failures into HTTP requests via a proxy server. 7. Monkey-ops : Monkey-Ops is a simple service implemented in Go, which is deployed into an OpenShift V3.X and generates some chaos within it. Monkey-Ops seeks some OpenShift components like Pods or Deployment Configs and randomly terminates them. 8. Chaos Dingo : Chaos Dingo currently supports performing operations on Azure VMs and VMSS deployed to an Azure Resource Manager-based resource group. 9. Tugbot : Testing in Production (TiP) framework for Docker. Testing tools

Slide 198

Slide 198 text

@arafkarsh arafkarsh References 198 CI / CD 1. What is Continuous Integration? 2. What is Continuous Delivery? 3. CI / CD Pipeline 4. What is CI / CD Pipeline? 5. CI / CD Explained 6. CI / CD Pipeline using Java Example Part 1 7. CI / CD Pipeline using Ansible Part 2 8. Declarative Pipeline vs Scripted Pipeline 9. Complete Jenkins Pipeline Tutorial 10. Common Pipeline Mistakes 11. CI / CD for a Docker Application

Slide 199

Slide 199 text

@arafkarsh arafkarsh References 199 DevOps 1. IBM: What is DevOps? 2. IBM: Cloud Native DevOps Explained 3. IBM: Application Transformation 4. IBM: Virtualization Explained 5. What is DevOps? Easy Way 6. DevOps?! How to become a DevOps Engineer??? 7. Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg 8. NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM 9. DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk 10. SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE 11. DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU 12. SRE @ Google: https://www.youtube.com/watch?v=d2wn_E1jxn4

Slide 200

Slide 200 text

@arafkarsh arafkarsh References 200 1. Lewis, James, and Martin Fowler. “Microservices: A Definition of This New Architectural Term”, March 25, 2014. 2. Miller, Matt. “Innovate or Die: The Rise of Microservices”. e Wall Street Journal, October 5, 2015. 3. Newman, Sam. Building Microservices. O’Reilly Media, 2015. 4. Alagarasan, Vijay. “Seven Microservices Anti-patterns”, August 24, 2015. 5. Cockcroft, Adrian. “State of the Art in Microservices”, December 4, 2014. 6. Fowler, Martin. “Microservice Prerequisites”, August 28, 2014. 7. Fowler, Martin. “Microservice Tradeoffs”, July 1, 2015. 8. Humble, Jez. “Four Principles of Low-Risk Software Release”, February 16, 2012. 9. Zuul Edge Server, Ketan Gote, May 22, 2017 10. Ribbon, Hysterix using Spring Feign, Ketan Gote, May 22, 2017 11. Eureka Server with Spring Cloud, Ketan Gote, May 22, 2017 12. Apache Kafka, A Distributed Streaming Platform, Ketan Gote, May 20, 2017 13. Functional Reactive Programming, Araf Karsh Hamid, August 7, 2016 14. Enterprise Software Architectures, Araf Karsh Hamid, July 30, 2016 15. Docker and Linux Containers, Araf Karsh Hamid, April 28, 2015

Slide 201

Slide 201 text

@arafkarsh arafkarsh References 201 16. MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx 17. Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html 18. Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ 19. Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs 20. Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer 21. CQS : http://en.wikipedia.org/wiki/Command–query_separation 22. CAP Theorem : http://en.wikipedia.org/wiki/CAP_theorem 23. CAP Theorem : http://www.julianbrowne.com/article/viewer/brewers-cap-theorem 24. CAP 12 years how the rules have changed 25. EBay Scalability Best Practices : http://www.infoq.com/articles/ebay-scalability-best-practices 26. Pat Helland (Amazon) : Life beyond distributed transactions 27. Stanford University: Rx https://www.youtube.com/watch?v=y9xudo3C1Cw 28. Princeton University: SAGAS (1987) Hector Garcia Molina / Kenneth Salem 29. Rx Observable : https://dzone.com/articles/using-rx-java-observable