Reactive Streams - Beware of Dangers!
summary
Reactive pipeline experience with RxJava and Reactive Streams shows concrete failure modes: processors commonly do not enforce backpressure so PublishProcessor drops events and UnicastProcessor uses an unbounded queue that can OOM with 10M events; ReplayProcessor’s size only limits replay to new subscribers, not global buffering. Caching and observeOn add hidden buffers and stale values across thousands of subscribers, async cancellation and dropped elements cause resource leaks, and missing stack traces make debugging costly; custom backpressure operators and exhaustive production-like tests are required to fix these failures.
AI-written summary · about
chapters (21)
- 0:00Introduction to reactive streams
- 1:07Reactive Streams API basics
- 3:02Choosing implementations
- 6:13Slow consumer problem
- 8:03Processor backpressure issues
- 11:18Server-side backpressure
- 13:07Threading and latency
- 16:25Backpressure operator solution
- 18:16Debugging reactive streams
- 20:00Error handling in pipelines
- 22:57Resource leaks in streams
- 25:04Buffering and memory issues
- 26:31Caching operator behavior
- 31:11Summary and best practices
- 34:13Q&A: Reactive vs virtual threads
- 35:40Q&A: WebFlux comparison
- 36:51Q&A: Narrow use cases
- 37:58Q&A: Custom operators
- 40:33Q&A: Lost subscribers debugging
- 42:18Q&A: Testing reactive code
- 44:03Q&A: Project usage frequency
related talks
01h 28mIntroduction to Reactive Programming
56mThirst-quenching Streams for the Reactive Mind
49mThirst Quenching Streams for the Reactive Mind
01h 01mFrom Reactive Extensions to Reactive Streams
01h 01mThirst Quenching Streams for the Reactive Mind
44mThirst-Quenching Streams for the Reactive Mind
38mRetrofit your Java App with a Reactive Flow Pipeline
37mReactive Pipeline Talk