Chapter 5. Reactive from Top to Bottom

Everything is a stream” is an often cited Zen of RxJava. In Chapter 4, we learned how to deploy RxJava in some places throughout our codebase. But what you will quickly discover is that truly reactive applications use streams pretty much from top to bottom. This approach simplifies reasoning and makes our application very consistent. Nonblocking applications tend to provide great performance and throughput for a fraction of the hardware. By limiting the number of threads, we are able to fully utilize CPU without consuming gigabytes of memory.

One of the limiting factors of scalability in Java is the I/O mechanism. The java.io package is very well designed with lots of small Input/OutputStream and Reader/Writer implementations that decorate and wrap one another, adding one functionality at a time. As much as I like this beautiful separation of concerns, standard I/O in Java is entirely blocking, meaning every thread that wishes to read or write from a Socket or File must wait indefinitely for the result. Even worse, threads stuck at an I/O operation due to slow network or an even slower spinning disk are hard to interrupt. Blocking on its own is not an issue, when one thread is blocked, others can still interact with remaining open Sockets. But threads are expensive to create and manage, and switching between them takes time. Java applications are perfectly capable of handling tens of thousands of concurrent connections, ...

Get Reactive Programming with RxJava now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.