Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Java Threads Rx Java Spring WebFlux WebSockets

Java Threads Rx Java Spring WebFlux WebSockets

Building Cloud-Native App Series - Part 4 of 15
Microservices Architecture Series
Concurrency & Parallelism
Java Concurrency
- 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
- Observables,
- Schedulers,
- Operators
Spring WebFlux
- Routers, Handlers
- Mono and Flux
- Server-Side Events
- Web Sockets
- WebFilter
- Exception Handling
- Debugging with Checkpoints, Hooks, DoOn, Logs

Araf Karsh Hamid

August 30, 2023
Tweet

More Decks by Araf Karsh Hamid

Other Decks in Technology

Transcript

  1. @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

    View Slide

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

    View Slide

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

    View Slide

  4. @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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. @arafkarsh arafkarsh
    Problem
    8
    Is Concurrency == Parallelism?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  13. @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.

    View Slide

  14. @arafkarsh arafkarsh
    Immutability
    o Object Immutability
    o Atomic Operations
    14

    View Slide

  15. @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.

    View Slide

  16. @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.

    View Slide

  17. @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.

    View Slide

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

    View Slide

  19. @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.

    View Slide

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

    View Slide

  21. @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.

    View Slide

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

    View Slide

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

    View Slide

  24. @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

    View Slide

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

    View Slide

  26. @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

    View Slide

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

    View Slide

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

    View Slide

  29. @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.

    View Slide

  30. @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

    View Slide

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

    View Slide

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

    View Slide

  33. @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.

    View Slide

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

    View Slide

  35. @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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  40. @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

    View Slide

  41. @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.

    View Slide

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

    View Slide

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

    View Slide

  44. @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.

    View Slide

  45. @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.

    View Slide

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

    View Slide

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

    View Slide

  48. @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

    View Slide

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

    View Slide

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

    View Slide

  51. @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.

    View Slide

  52. @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

    View Slide

  53. @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

    View Slide

  54. @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

    View Slide

  55. @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.

    View Slide

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

    View Slide

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

    View Slide

  58. @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.

    View Slide

  59. @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.

    View Slide

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

    View Slide

  61. @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.

    View Slide

  62. @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.

    View Slide

  63. @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

    View Slide

  64. @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

    View Slide

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

    View Slide

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

    View Slide

  67. @arafkarsh arafkarsh
    Asynchronous API
    o Future
    o Completable Future
    67

    View Slide

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

    View Slide

  69. @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

    View Slide

  70. @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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  75. @arafkarsh arafkarsh
    Completable Future Example
    75

    View Slide

  76. @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

    View Slide

  77. @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.

    View Slide

  78. @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.

    View Slide

  79. @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

    View Slide

  80. @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

    View Slide

  81. @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

    View Slide

  82. @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

    View Slide

  83. @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

    View Slide

  84. @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

    View Slide

  85. @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

    View Slide

  86. @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

    View Slide

  87. @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

    View Slide

  88. @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.

    View Slide

  89. @arafkarsh arafkarsh
    Compare Iterable Vs. Observable
    31 August 2023 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

    View Slide

  90. @arafkarsh arafkarsh
    Comparison : Iterable / Streams / Observable
    31 August 2023 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

    View Slide

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

    View Slide

  92. @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

    View Slide

  93. @arafkarsh arafkarsh
    RxJava Scheduler Threading Details
    31 August 2023 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

    View Slide

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

    View Slide

  95. @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

    View Slide

  96. @arafkarsh arafkarsh
    RxJava : Examples – Handling Fruit Processor
    31 August 2023 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

    View Slide

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

    View Slide

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

    View Slide

  99. @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

    View Slide

  100. @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

    View Slide

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

    View Slide

  102. @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

    View Slide

  103. @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

    View Slide

  104. @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

    View Slide

  105. @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

    View Slide

  106. @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 to Observable
    Rx Example 2
    Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

    View Slide

  107. @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.

    View Slide

  108. @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 to Observable
    Source: https://github.com/arafkarsh/fusion-sky-threads-rx-java

    View Slide

  109. @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/

    View Slide

  110. @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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  118. @arafkarsh arafkarsh
    8/31/23
    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

    View Slide

  119. @arafkarsh arafkarsh
    8/31/23
    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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  124. @arafkarsh arafkarsh
    SpringBoot WebFlux
    124

    View Slide

  125. @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.

    View Slide

  126. @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.

    View Slide

  127. @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

    View Slide

  128. @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

    View Slide

  129. @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.

    View Slide

  130. @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.

    View Slide

  131. @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.

    View Slide

  132. @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.

    View Slide

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

    View Slide

  134. @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

    View Slide

  135. @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.

    View Slide

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

    View Slide

  137. @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

    View Slide

  138. @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

    View Slide

  139. @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

    View Slide

  140. @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.
    This is not because of any
    limitation in returning a Flux but
    because the router function is
    supposed to produce a single
    ServerResponse object to
    handle the HTTP request.
    The Mono
    encapsulates the HTTP
    response, including the status
    code, headers, and body. If you
    want the body of the HTTP
    response to contain a stream of
    values (e.g., a JSON array), then
    that stream should be a Flux
    and wrapped inside the
    ServerResponse object.
    Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

    View Slide

  141. @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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  147. @arafkarsh arafkarsh
    Server-Side Events: Result
    147

    View Slide

  148. @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.

    View Slide

  149. @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.

    View Slide

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

    View Slide

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

    View Slide

  152. @arafkarsh arafkarsh
    Web Socket – Streaming Data
    152
    Source: https://github.com/arafkarsh/ms-springboot-310-webflux-r2dbc

    View Slide

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

    View Slide

  154. @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.

    View Slide

  155. @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.

    View Slide

  156. @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.

    View Slide

  157. @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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  163. @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.

    View Slide

  164. @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.

    View Slide

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

    View Slide

  166. @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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  171. @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.

    View Slide

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

    View Slide

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

    View Slide

  174. @arafkarsh arafkarsh
    doOnNext – More Logs
    174

    View Slide

  175. @arafkarsh arafkarsh
    doOnError – More Logs
    175

    View Slide

  176. @arafkarsh arafkarsh
    doOnComplete – More Logs
    176

    View Slide

  177. @arafkarsh arafkarsh
    doOnTerminate – More Logs
    177

    View Slide

  178. @arafkarsh arafkarsh
    doOnEach – More Logs
    178

    View Slide

  179. @arafkarsh arafkarsh
    Hooks
    179

    View Slide

  180. @arafkarsh arafkarsh
    Hooks
    180

    View Slide

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

    View Slide

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

    View Slide

  183. @arafkarsh arafkarsh 183
    Source Code: https://github.com/arafkarsh Web Site: https://arafkarsh.com/ https://pyxida.cloud/

    View Slide

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

    View Slide

  185. @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

    View Slide

  186. @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

    View Slide

  187. @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

    View Slide

  188. @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.

    View Slide

  189. @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

    View Slide

  190. @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

    View Slide

  191. @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

    View Slide

  192. @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?

    View Slide

  193. @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

    View Slide

  194. @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

    View Slide

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

    View Slide

  196. @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

    View Slide

  197. @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

    View Slide

  198. @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

    View Slide

  199. @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

    View Slide