Hot Streams are preferred in applications in which some of its features depend on data resources that are not fixed and most of the time unknown. To avoid overflows and series of exceptions and leaks, hot Streams are used for the recipients not to pull the data but just to connect and listen to incoming Streams, if any, and observe the built-in backpressure and concurrent loosely coupled event executions.

This recipe highlighted two ways to generate hot Streams and that is through ConnectableFlux<T> and Processor<T>. The easiest way of converting a typical cold Stream to a hot Stream is through the use of ConnectableFlux<T>. This flux creates a continuous flow of Stream from a data repository or from a huge datasource wherein the flow of execution has started even before any recipients connect to it. Since ConnectableFlux<T> does not need subscribe() to execute it, the only way to observe its Stream is to establish a connection. The recipient must explicitly call connect() and the very reason why no subscription is needed is its behavior as both publisher and subscriber. This Flux supports multiple subscriptions as seen in this recipe, freeFlowEmps() which creates a hot Stream that implements a continuous flow of current Employee Stream elements from the current snapshot of the database with two subscribers doing different result Callback executions.

On the other hand, using Processor<T> is more robust, pre-packaged, and direct than the former. It has a built-in asynchronous computing capability to execute Stream operations and has back-pressure support. Some of these processors have a caching mechanism to execute proper subscriptions. Just like ConnectableFlux<T>, a processor is both a publisher and a subscriber and the only way to use the hot Stream they generate is to connect() with them too.