https://github.com/claudio-code/java-reactive-programming
:scroll: Learning to use reactive programming with java.
https://github.com/claudio-code/java-reactive-programming
Last synced: 8 months ago
JSON representation
:scroll: Learning to use reactive programming with java.
- Host: GitHub
- URL: https://github.com/claudio-code/java-reactive-programming
- Owner: Claudio-code
- Created: 2022-06-24T01:00:23.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2022-08-14T23:54:48.000Z (over 3 years ago)
- Last Synced: 2025-02-15T20:54:11.953Z (10 months ago)
- Language: Java
- Size: 23.4 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# About project
- Learning how use reactor pattern implementation in Java.
- The Reactor have two implementation of Publishers is Mono and Flux.
- Mono:
- Can send 0 or 1 item.
- Can be followed by onComplete / onError methods.
- Flux:
- Can send 0 or N items.
- Can be followed by onComplete / onError methods too.
---
### Schedulers != Parallel-execution
- All the operations are always executed in sequential.
- Data is processed one by one via 1 thread in the ThreadPool for a Subscriber.
- Schedulers.parallel() - Is a thread poll for CPU tasks. Does not mean parallel execution.
---
### Flux - create / generate
| Create | Generate |
|-----------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------|
| Accepts a `Consumer>` | Accepts a `Consumer>` |
| Consumer is invoked only once | Consumer is invoked again based on the downstream demand |
| Consumer can emit 0..N elements immediately | Consumer can emit only one elements |
| Publisher might not be aware of downstream processing speed. So we need to provide `Overflow Strategy` as an additional parameter | Publisher produces elements based on the downstream demand |
| Thread-safe | N/A |
| `fluxSink.requestedFromDownstream()` and `fluxSink.isCancelled()` | N/A |
---
### Schedulers
| Schedulers Method | Usage |
|-------------------|----------------------------------------------|
| BoundedElastic | Network / time-consuming calls |
| Parallel | CPU intensive tasks |
| Single | A single dedicated thread for one-off tasks |
| Immediate | Current thread |
---
### Operators for Scheduling
| Operator | Usage |
|-------------|----------------|
| subscribeOn | for upstream |
| publishOn | for downstream |
----
### Overflow Strategy
| Strategy | Behavior |
|----------|-----------------------------------------------------------------------------|
| Buffer | Keep in memory |
| Drop | Once the queue is full, new items will be dropped |
| Latest | Once the queue is full, keep 1 latest item as and when it arrives, drop old |
| Error | Throw error to the downstream |
- Buffer
- With BUFFER strategy, as name suggests all values are buffered so that subscriber can receive all values. As per program below, buffer is infinite, so if published values are large in count & subscriber is too slow, then there is chance of out of memory just like Observable.
- Drop
- DROP strategy drops the most recent next value if the downstream can’t keep up because its too slow. There are also ways provided to consume dropped values and handle them separately.
- Latest
- LATEST strategy keeps only the latest next value, overwriting any previous value if the downstream can’t keep up because its too slow.
- Error
- ERROR strategy throws OverflowException in case the downstream can’t keep up due to slowness. Publisher can handle exception & make sure to call error handle so that subscriber can do handling on subscriber side for such error scenarios.
---
---
## Stack used
- Java 17 lts
- Maven