Java Threads Rx Java Spring WebFlux WebSockets

@arafkarsh arafkarsh 8 Years Network & Security 6+ Years Microservices
Blockchain 8 Years Cloud Computing 8 Years Distributed Computing Architecting & Building Apps a tech presentorial Combination of presentation & tutorial ARAF KARSH HAMID Co-Founder / CTO MetaMagic Global Inc., NJ, USA @arafkarsh arafkarsh 1 Microservice Architecture Series Building Cloud Native Apps 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 Part 4 of 15

@arafkarsh arafkarsh 2 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

@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 3

@arafkarsh arafkarsh Package Structure 4 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

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

@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 6 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

@arafkarsh arafkarsh Application Modernization – 3 Transformations 7 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

@arafkarsh arafkarsh Problem 8 Is Concurrency == Parallelism?

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

@arafkarsh arafkarsh Concurrency 10 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.

@arafkarsh arafkarsh Parallelism 11 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.

@arafkarsh arafkarsh Comparison 12 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.

@arafkarsh arafkarsh Summary 13 • 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.

@arafkarsh arafkarsh Immutability o Object Immutability o Atomic Operations 14

@arafkarsh arafkarsh Immutable Objects 15 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.

@arafkarsh arafkarsh Atomic Operations on Primitives 16 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.

@arafkarsh arafkarsh Compare and Swap (CAS) 17 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.

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

@arafkarsh arafkarsh Why is the Example 1 Not Thread safe?
19 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.

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

@arafkarsh arafkarsh Why Example 2 thread safe? 21 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.

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

@arafkarsh arafkarsh Synchronization 23 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.

@arafkarsh arafkarsh Compare 24 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

@arafkarsh arafkarsh Semaphore 25 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.

@arafkarsh arafkarsh Semaphore Java Example 26 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

@arafkarsh arafkarsh Monitor 27 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.

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

@arafkarsh arafkarsh Java notify() 29 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.

@arafkarsh arafkarsh Java notifyAll() 30 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

@arafkarsh arafkarsh MutEx 31 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.

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

@arafkarsh arafkarsh Conditions with Mutex - ReentrantLock 33 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.

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

@arafkarsh arafkarsh Understanding the Producer Code 35 • 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.

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

@arafkarsh arafkarsh ReadWriteLock 37 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.

@arafkarsh arafkarsh ReadWriteLock 38 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.

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

@arafkarsh arafkarsh ReadWriteLock – Example 40 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

@arafkarsh arafkarsh Count Down Latch 41 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.

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

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

@arafkarsh arafkarsh Feature Comparison 44 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.

@arafkarsh arafkarsh Cyclic Barrier 45 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.

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

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

@arafkarsh arafkarsh Exchanger 48 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

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

@arafkarsh arafkarsh Phaser 50 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.

@arafkarsh arafkarsh Phaser – Objectives 51 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.

@arafkarsh arafkarsh Phaser – Example 52 • 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

@arafkarsh arafkarsh Phaser – Example 53 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

@arafkarsh arafkarsh Comparison 54 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

@arafkarsh arafkarsh Summary 55 • 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.

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

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

@arafkarsh arafkarsh Thread Pools 58 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.

@arafkarsh arafkarsh Thread Pool with Executor Service 59 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.

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

@arafkarsh arafkarsh Thread Groups 61 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.

@arafkarsh arafkarsh Thread Pool with Thread Groups 62 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.

@arafkarsh arafkarsh Thread Pool with Thread Group 63 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

@arafkarsh arafkarsh Summary 64 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

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

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

@arafkarsh arafkarsh Asynchronous API o Future o Completable Future 67

@arafkarsh arafkarsh Future 68 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.

@arafkarsh arafkarsh Future Example 69 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

@arafkarsh arafkarsh Completable Future 70 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.

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

@arafkarsh arafkarsh Comparison 72 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.

@arafkarsh arafkarsh Comparison 73 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.

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

@arafkarsh arafkarsh Completable Future Example 75

@arafkarsh arafkarsh Comparison – Future / Completable Future 76 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

@arafkarsh arafkarsh Completable Future and Rx Java 77 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.

@arafkarsh arafkarsh Completable Future and Rx Java 78 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.

@arafkarsh arafkarsh Comparison 79 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

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

@arafkarsh arafkarsh Functional Reactive Programming 81 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

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

@arafkarsh arafkarsh Functional Reactive Programming : Design Patterns 83 83
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

@arafkarsh arafkarsh 4 Building Blocks of RxJava 84 84 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

@arafkarsh arafkarsh 4 Building Blocks of RxJava 85 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

@arafkarsh arafkarsh Observable Design Pattern (Marble Diagram) 1 Building Block
86 • 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

@arafkarsh arafkarsh Observable / Observer Design Pattern 87 • 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

@arafkarsh arafkarsh What’s missing from GOF Observer Pattern 88 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.

@arafkarsh arafkarsh Compare Iterable Vs. Observable 02 April 2024 89
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

@arafkarsh arafkarsh Comparison : Iterable / Streams / Observable 02
April 2024 90 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

@arafkarsh arafkarsh Observer<T> Contract 91 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

@arafkarsh arafkarsh RxJava Scheduler Details 92 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

@arafkarsh arafkarsh RxJava Scheduler Threading Details 02 April 2024 93
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

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

@arafkarsh arafkarsh The Problem? How Rx Helps! 95 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

@arafkarsh arafkarsh RxJava : Examples – Handling Fruit Processor 02
April 2024 96 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

@arafkarsh arafkarsh RxJava : Entities & Repositories 02 April 2024
97 1 Building Block Fruit Interface Abstract Fruit Fruit Repository Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

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

@arafkarsh arafkarsh Rx 2 Java : Apple Fruit Basket :
Observable 99 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

@arafkarsh arafkarsh Rx 2 Java : Fruit Processor : Observer
100 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

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

@arafkarsh arafkarsh Rx 2 Java Operator : Merge 3 Streams
102 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

@arafkarsh arafkarsh Rx 2 Java Operator : Merge / Filter
Streams 103 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

@arafkarsh arafkarsh RxJava Operator : Merge / Filter Streams 104
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

@arafkarsh arafkarsh Rx 2 Java Operator : Merge / Filter
/ Sort 105 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

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

@arafkarsh arafkarsh The Problem? How Rx Helps! 107 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.

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

@arafkarsh arafkarsh RxJava Operator Details 109 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/

@arafkarsh arafkarsh Rx 2 Java Operator Details 110 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

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

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

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

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

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

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

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

@arafkarsh arafkarsh 4/2/2024 118 • 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

@arafkarsh arafkarsh 4/2/2024 119 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.

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.

2 Migration Object Method Call import rx.Observable; Observable Observable Join(Observable, Func1) Observable<Boolean> 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<Boolean> all(Predicate) Observable amb(Iterable<ObservableSource>) 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.

2 Migration Object Method Call import rx.Observable; Observable countLong() Observable static Observable create(Action1<Emitter>, 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.

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

@arafkarsh arafkarsh SpringBoot WebFlux 124

@arafkarsh arafkarsh Springboot MVC 125 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.

@arafkarsh arafkarsh Springboot MVC: How it works? 126 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.

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

@arafkarsh arafkarsh SpringBoot MVC 128 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

@arafkarsh arafkarsh Springboot WebFlux 129 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.

@arafkarsh arafkarsh Springboot WebFlux: How it works? 130 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.

@arafkarsh arafkarsh Springboot WebFlux: How it works? 131 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.

@arafkarsh arafkarsh WebFlux Internals 132 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.

@arafkarsh arafkarsh Spring MVC Vs WebFlux 133 SpringBoot MVC SpringBoot
WebFlux

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

@arafkarsh arafkarsh Servlet and Reactive – Life Cycle 135 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.

@arafkarsh arafkarsh Comparison 136 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.

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

@arafkarsh arafkarsh RestController – Exception from Service 138 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

@arafkarsh arafkarsh RestController – Exception from Controller 139 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

@arafkarsh arafkarsh Router (instead of Rest Controller) 140 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<ServerResponse>. 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<ServerResponse> 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

@arafkarsh arafkarsh Router / Handlers – Exceptions 141 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

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

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

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

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

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

@arafkarsh arafkarsh Server-Side Events: Result 147

@arafkarsh arafkarsh How Server-Side Events (SSE) Work? 148 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.

@arafkarsh arafkarsh Server-Side Events – Streaming Data 149 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.

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

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

@arafkarsh arafkarsh Web Socket – Streaming Data 152 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.

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

@arafkarsh arafkarsh How Web Sockets work? 154 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.

@arafkarsh arafkarsh Web Sockets 155 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.

@arafkarsh arafkarsh Web Sockets 156 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.

@arafkarsh arafkarsh Web Sockets 157 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.

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

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

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

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

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

@arafkarsh arafkarsh Debugging Options 163 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.

@arafkarsh arafkarsh Debugging Options 164 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.

@arafkarsh arafkarsh Checkpoints o Logs and Checkpoints o Conditional Checkpoints
165

@arafkarsh arafkarsh Checkpoint – Stack Traces & Logging 166 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

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

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

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

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

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

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

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

@arafkarsh arafkarsh doOnNext – More Logs 174

@arafkarsh arafkarsh doOnError – More Logs 175

@arafkarsh arafkarsh doOnComplete – More Logs 176

@arafkarsh arafkarsh doOnTerminate – More Logs 177

@arafkarsh arafkarsh doOnEach – More Logs 178

@arafkarsh arafkarsh Hooks 179

@arafkarsh arafkarsh Hooks 180

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

@arafkarsh arafkarsh 182 Thank you DREAM | AUTOMATE | EMPOWER
Araf Karsh Hamid : India: +91.999.545.8627 http://www.slideshare.net/arafkarsh https://speakerdeck.com/arafkarsh https://www.linkedin.com/in/arafkarsh/ https://www.youtube.com/user/arafkarsh/playlists http://www.arafkarsh.com/ @arafkarsh arafkarsh

@arafkarsh arafkarsh 183 Source: https://github.com/arafkarsh Web: https://arafkarsh.com/ Slides: https://speakerdeck.com/arafkarsh

@arafkarsh arafkarsh 184 http://www.slideshare.net/arafkarsh

@arafkarsh arafkarsh References 185 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

@arafkarsh arafkarsh References 186 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

@arafkarsh arafkarsh References 187 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

@arafkarsh arafkarsh References – Microservices – Videos 188 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.

@arafkarsh arafkarsh References 189 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

@arafkarsh arafkarsh References 190 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

@arafkarsh arafkarsh References 191 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

@arafkarsh arafkarsh References 192 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?

@arafkarsh arafkarsh References 193 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

@arafkarsh arafkarsh References 194 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

@arafkarsh arafkarsh 195 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

@arafkarsh arafkarsh References 196 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

@arafkarsh arafkarsh References 197 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

@arafkarsh arafkarsh References 198 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

@arafkarsh arafkarsh References 199 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

Java Threads Rx Java Spring WebFlux WebSockets

Java Threads Rx Java Spring WebFlux WebSockets

More Decks by Araf Karsh Hamid

Other Decks in Technology

Featured

Transcript