What are reactive streams and what's so special in them?

Question

I browsed Wikipedia and encountered a new feature of Java 1.9: Reactive streams.

Unfortunately, the linked Wikipedia page doesn't help much to understand what those reactive streams are and what's so special in them.

It was said they are asynchronous, so apparently there's some kind of buffer. It was also said there's non-blocking back pressure. But what is exactly non-blocking back pressure?

How do reactive streams differ from previous concurrency tools such as blocking / non-blocking queues? Are they byte streams like TCP or message streams like UDP/SCTP? Is there a guarantee of in-order delivery like in SCTP or can the data units be reordered like in UDP? Are reactive streams reliable like TCP and SCTP or is it possible that data is dropped like in UDP?

Extra points will be given if the answer includes a concrete example of a problem that is hard to solve with previous concurrency tools, but easy to solve with reactive streams.

Answer 1

Related on SO: https://stackoverflow.com/questions/1216380/what-is-a-stream

TCP, UDP and SCTP aren't streams - they are transport protocols. A Stream might be implemented using any of those transport protocols, or indeed may be implemented using a named pipe, a shared memory buffer, an MQ technology...

A stream is an abstraction which hides that kind of low-level detail and presents your program with a mechanism to transmit or receive some series of objects or bytes.

A stream is a solution for problems related to communication. This can include network communication, inter-process communication, inter-thread communication, or even communication with a hardware device or file.

The term reactive is referring to the Reactive Programming Model, which is focused on how to structure code responsible for receiving data asynchronously.

At the simplest level, streams are typically presented to a recipient via some kind of buffer, often with a thread-safety mechanism to ensure that reading/writing happens atomically.

Receiving data from a stream without a reactive abstraction typically involves techniques such as "polling" (periodic inspection) or blocking a thread and waiting for data - Often the solution results in creating your own reactive abstraction around that stream.

A reactive stream may use a different model such as an event signal, or may be an abstraction around a polling and/or "waiting thread". The term 'reactive' implies data is received asynchronously (note: that doesn't necessarily mean concurrently) - A reactive abstraction usually requires you attach a callback, observer or event handler to handle inbound data from that stream.

A stream may or may not be responsible for ordering, reliable delivery, buffering, etc; these are concerns which are generally tied up in the implementation detail of the stream (or perhaps the underlying transport).

---

On a specific note about the Java Reactive Streams library; the concept is clearly nothing new. Reactive streams in Java have always been possible.

The rationale for Java's new library is explained at the top of this page: http://www.reactive-streams.org/

Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure.

In other words, it looks as if Java is attempting to provide a set of standard interfaces and workflows for reactive streams; which (I assume, I am not a Java Programmer..) probably means that current support for reactive stream abstractions is inconsistent and fragmented.

In simple terms, it looks as if the Reactive Streams library is attempting to solve another important problem for Java programmers - consistency.

Answer 2

Reactive streams are special form of asynchronous programming. Asynchronous programming uses asynchronous procedure calls (APC) instead of threads. The main goal is to save core memory, as each thread consumes a lot of memory for its call stack (0.5-1 MB), while APC uses stack only when actively running. As a result, a small number of working threads (roughly equals to the number of available processors) is able to serve millions of APCs.

All multithreading communication facilities (including BlockingQueues) has their analogues in the asynchronous world. Moreover, there exist means to connect APCs and threads (e.g. implementations of java.util.concurrent.Future). So you can first design your parallel program as directed graph where nodes are abstract activities connected with message queues, and then when implementing, decide if this or that activity can be better implemented as a thread or as a APC. Note APCs can be repeatable, e.g. Akka actors.