title: Edited: Retrofit and CompletableFuture, is there a way to not rely on the underlying connection pool?
body: <p>Original question:</p>
  <blockquote>
  <p>OkHttp, is there a way to not rely on a connection pool?</p>
  </blockquote>
  <p>Hey OkHttp users and/or contributors!</p>
  <p>Is there a way to use an OkHttpClient without any pool of connections ? That is, in other words, is it possibile to fire one or a few HTTP request from the same thread in which <code>myClient.execute()</code> method is invoked?</p>
  <p>I tried to find a clear answer online but this is all I found:</p>
  <ul>
  <li>by default a connection pool is used, and as such my understanding is that an HTTP request will be always fired from one of the threads that are instantiated and kept alive by the OkHttp client</li>
  <li>It’s possible to configure a custom ExecutorService at the client level. Theoretically, I could define a single threaded executor, but that would anyway come with a dedicated extra thread (and not the parent one in my invocation stack). moreover, such a “solution” would be impractical as it would cause queuing issues under a non negligible load, assuming a singleton instance of the client is being used.</li>
  </ul>
  <p>I could not find a way to take over parallelism <strong>at the Request level</strong>. The only workaround I can currently think of is as follows:</p>
  <ul>
  <li>single threaded executor setup</li>
  <li>Multiple client instances, each for any request (or set of requests of the same functional flow)</li>
  </ul>
  <p>The above would anyway not solve my problem completely, as there is anyway an extra thread per request/s. Moreover, based on the documentation I found online the shared best practice when using OkHttp is to share a singleton client instance amongst multiple threads.</p>
  <p>Thanks a lot!</p>
  <p>Ps: for context, the reason I’m asking is that ~a customer~ a friend of mine has a logger implementation that relies on <code>ThreadLocal</code>s to correlate HTTP requests logs, produced by the client instance via an <em>application interceptor</em>. They’re replacing their existing, vintage integration with my company payments API with a brand new SDK we’re offering, that arguably deals with concurrency differently from what they were used.</p>
  <h2>Edits</h2>
  <p><a href="https://stackoverflow.com/a/72064728/5779776">This reply</a> shed a light on the original question I had:
  Yes, it's possible to use OkHttp synchronously on the main thread, by just using the <code>execute()</code> method offered by the <code>Call</code> type.</p>
  <p>The behavior I'm experiencing (all calls submitted to a thread pool) is due to the fact that I'm using Retrofit along with <code>CompletableFuture&lt;T&gt;</code>s declared as response types of my REST API endpoints. For instance:</p>
  <pre><code>@GET(&quot;/payments/{id}&quot;)
      CompletableFuture&lt;ApiResponse&lt;PaymentDetail&gt;&gt; getPayment(@Path(&quot;id&quot;) String paymentId);
  </code></pre>
  <p>Actually, in my particular case I've also a custom call adapter that adapts a <code>CompletableFuture&lt;T&gt;</code> into a <code>CompletableFuture&lt;ApiResponse&lt;T&gt;&gt;</code> for an improved error handling, but this <strong>should not be relevant</strong> in this scope.</p>
  <p>My outstanding questions are, eventually:</p>
  <ol>
  <li>When using Retrofit's CompletableFuture adapter, how that affects Okhttp multithreading ? In other words, is my understanding correct that when dealing with responsens of CompletableFuture in Retrofit, we always submit the HTTP request to one of the threads that's available in the OkhttpClient <a href="https://square.github.io/okhttp/4.x/okhttp/okhttp3/-dispatcher/" rel="nofollow noreferrer">Dispatcher</a> ?</li>
  <li>Am I right in saying that regardless of the synchronous or asynchronous model used on Retrofit/OkHttp, OkHttp's connection pool is always being used ?</li>
  <li>Is it right to say that when using a synchronous model, OkHttp's Dispatcher (even the default one) is irrelevant ? If so, is there a way to not have any thread pool provisioned by OkHttp ?</li>
  </ol>