An operator that consumes more time in computations is a serious problem when creating Streams. Usually, when operations are involved in some I/O tasks, file content retrieval, or selecting records from an archive data warehouse, it is always recommended to generate threads that work in parallel mode in order to attend to these heavy operations.

Parallelism starts with a parallel() operator which creates a pool of t threads. These t threads will eventually become rails of parallel Flux after the runOn() method is invoked. After all the parallel tasks are done executing, these Streams can be merged into one resulting Stream by calling the sequential() method. It is a must to call sequential() since subscription cannot be parallelized easily. But, to really implement 100% parallelism where the subscription process is also part of the concurrency, use grouped parallel flux. Each rail is internally paired to a subscription through an internally-created key, to represent a grouped parallel flux of Stream type Flux<GroupedFlux<java.lang.Integer,T>>. Applying groups is the same concept of implementing parallelism to publisher-subscriber by grouping basis.

To add more concurrency power to the reactor stream, we can include the repeat() operator to repeat the Stream processes at least once. After the completion of all Streams, repeat() triggers re-subscription eventually executing parallel(), runOn(), and sequential() operators again and again with an unpredictable task assignment to the thread pool. Also, the subscription will also be effective and traceable if certain backpressure will be applied like the use of the delayElements() operator.