title: publishOn vs subscribeOn when making a blocking call in Reactor
body: <p>In the blog post <a href="https://spring.io/blog/2019/12/13/flight-of-the-flux-3-hopping-threads-and-schedulers" rel="nofollow noreferrer">Flight of the Flux 3</a>, the authors suggest wrapping a synchronous blocking call in a <code>Mono</code> with a <code>subscribeOn</code> call, as shown in this snippet from the article:</p>
  <pre><code>final Flux&lt;String&gt; betterFetchUrls(List&lt;String&gt; urls) {
    return Flux.fromIterable(urls)
      .flatMap(url -&gt; 
               //wrap the blocking call in a Mono
               Mono.fromCallable(() -&gt; blockingWebClient.get(url))
               //ensure that Mono is subscribed in an boundedElastic Worker
               .subscribeOn(Schedulers.boundedElastic())
      ); //each individual URL fetch runs in its own thread!
  }
  </code></pre>
  <p>But earlier in the same post, they show that you can use <code>publishOn</code> to ensure a blocking call is done on a separate thread:</p>
  <pre><code>Flux.fromIterable(firstListOfUrls) //contains A, B and C
      .publishOn(Schedulers.boundedElastic())
      .map(url -&gt; blockingWebClient.get(url))
      .subscribe(body -&gt; System.out.println(Thread.currentThread().getName + &quot; from first list, got &quot; + body));
  </code></pre>
  <p>Given that, why not just implement the <code>betterFetchUrls</code> method using <code>publishOn</code> directly?</p>
  <pre><code>final Flux&lt;String&gt; betterFetchUrls(List&lt;String&gt; urls) {
      return Flux.fromIterable(urls)
          .publishOn(Schedulers.boundedElastic())
          .map(url -&gt; blockingWebClient.get(url));
  }
  </code></pre>
  <p>Isn't that simpler? The Reference Manual for Reactor in <a href="https://projectreactor.io/docs/core/release/reference/#faq.wrap-blocking" rel="nofollow noreferrer">Appendix C</a> also does the wrapped call in a <code>Mono</code> with a <code>subscribeOn</code>, so I presume there must be a reason that's preferred, but I can't figure out what that reason might be.</p>
  <p>Thanks for any insight.</p>