Why does not the runOn() method execute map operator on the next available thread from the pool when the current executing threads go to wait state? - project-reactor

Question

I am trying to execute the following code on a 4 core machine. I have 5 threads in the pool and within the map operator, I put the executing thread to sleep for a few seconds.
I expect that the core would put the executing thread on sleep and when the next event is available, should perform the map operation on the next available thread from the thread pool, BUT is not the behavior I see.
I see that the 4 threads from the pool go on wait for 13 seconds and process the next event only after the wait is complete.
Why is the runOn() method not executing the map operator on the next available thread from the pool when the threads go to wait state?
I am using reactor-core version '3.0.7.RELEASE'
CountDownLatch latch = new CountDownLatch(10);
ExecutorService executorService = Executors.newFixedThreadPool(5);
Flux<Integer> flux = Flux.just(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
flux.parallel()
.runOn(Schedulers.fromExecutorService(executorService))
.map(l -> {
Logger.log(ReactorParallelTest.class, "map1", "inside run waiting for 13 seconds");
try {
Thread.sleep(13000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Logger.log(ReactorParallelTest.class, "map1", "l=" + l);
latch.countDown();
return l;
}).subscribe(l -> {
Logger.log(ReactorParallelTest.class, "onNext", "l=" + l);
}, error -> System.err.println(error),
() -> {
Logger.log(ReactorParallelTest.class, "onComplete", "inside complete.");
executorService.shutdown();
});
try {
latch.await(60, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}

Answer 1

You are blocking all your rails with this code. 4 rails will be started (number of CPUs), and they will immediately request 1 element each from the source. Since you immediately block in the map when this is done, the rail cannot request more from upstream, so in effect you only get 4 elements at a time, block, get more, block... The parallelism is more limited than the capacity of the thread pool. If you want to put all threads to good use, do .parallel(5) (same configuration as the thread pool).
On a side note, the subscribe(lambda) from ParallelFlux will invoke the onComplete callback for each rail. If you want to merge back to a single sequence (and single complete), use a .sequential() just before .subscribe.