* cache size. The application needs to be aware of calling this function during the
   * initialization phase and preferably in a background worker thread.
   *
   * Note that if the application chooses to not call this method to initialize the cache. By
   * default, OkHttp will perform lazy initialization upon the first usage of the cache.
   */

      isRunning = runningCallsCount() > 0
    }

    // Avoid resubmitting if we can't logically progress
    // particularly because RealCall handles a RejectedExecutionException
    // by executing on the same thread.
    if (executorService.isShutdown) {
      for (i in 0 until executableCalls.size) {
        val asyncCall = executableCalls[i]
        asyncCall.callsPerHost.decrementAndGet()

        this.withLock {

    }
    body.awaitSuccess()
  }

  /**
   * Duplex calls that have follow-ups are weird. By the time we know there's a follow-up we've
   * already split off another thread to stream the request body. Because we permit at most one
   * exchange at a time we break the request stream out from under that writer.
   */
  @Test
  fun duplexWithRedirect() {
    enableProtocol(Protocol.HTTP_2)

/**
 * Factory for [calls][Call], which can be used to send HTTP requests and read their responses.
 *
 * ## OkHttpClients Should Be Shared
 *
 * OkHttp performs best when you create a single `OkHttpClient` instance and reuse it for all of
 * your HTTP calls. This is because each client holds its own connection pool and thread pools.
 * Reusing connections and threads reduces latency and saves memory. Conversely, creating a client

import okhttp3.internal.ws.WebSocketProtocol.toggleMask
import okio.Buffer
import okio.BufferedSource
import okio.ByteString

/**
 * An [RFC 6455][rfc_6455]-compatible WebSocket frame reader.
 *
 * This class is not thread safe.
 *
 * [rfc_6455]: http://tools.ietf.org/html/rfc6455
 */
class WebSocketReader(
  private val isClient: Boolean,
  val source: BufferedSource,
  private val frameCallback: FrameCallback,

    of unacknowledged data per stream and no per-connection limit.

 *  Fix: Don't close a `Deflater` while we're still using it to compress a web socket message. We
    had a severe bug where web sockets were closed on the wrong thread, which caused
    `NullPointerException` crashes in `Deflater`.

 *  Fix: Don't crash after a web socket fails its connection upgrade. We incorrectly released

  private fun sleep(delayMillis: Int) {
    try {
      Thread.sleep(delayMillis.toLong())
    } catch (e: InterruptedException) {
      Thread.currentThread().interrupt()
    }
  }

  private fun cancelLater(
    call: Call,
    delayMillis: Int,
  ): CountDownLatch {
    val latch = CountDownLatch(1)
    Thread {
      sleep(delayMillis)
      if (cancelMode == CANCEL) {

HSPLkotlinx/coroutines/AbstractCoroutine;->resumeWith(Ljava/lang/Object;)V
HSPLkotlinx/coroutines/Active;-><clinit>()V
HSPLkotlinx/coroutines/Active;-><init>()V
HSPLkotlinx/coroutines/BlockingEventLoop;-><init>(Ljava/lang/Thread;)V
HSPLkotlinx/coroutines/CancelHandler;-><init>()V
HSPLkotlinx/coroutines/CancellableContinuationImpl;-><clinit>()V
HSPLkotlinx/coroutines/CancellableContinuationImpl;-><init>(Lkotlin/coroutines/Continuation;I)V

    // Enqueueing the red task starts a thread because the head of the queue changed.
    redQueue.execute("red task") {
      log += "red:starting@${taskFaker.nanoTime}"
      taskFaker.sleep(100.µs)
      log += "red:finishing@${taskFaker.nanoTime}"
    }
    assertThat(taskFaker.executeCallCount).isEqualTo(1)

    // Enqueueing the blue task doesn't start a thread because the red one is still starting.

    // A conditional cache hit updates the cache.
    Thread.sleep(500) // Make sure t0 and t1 are distinct.
    val t1 = System.currentTimeMillis()
    val response2 = get(server.url("/a"))
    assertThat(response2.code).isEqualTo(HttpURLConnection.HTTP_OK)
    assertThat(response2.body.string()).isEqualTo("A")
    assertThat(response2.header("Allow")).isEqualTo("GET, HEAD")
    val updatedTimestamp = response2.receivedResponseAtMillis