"--connect-timeout",
    help = "Maximum time allowed for connection (seconds)",
  ).int().default(DEFAULT_TIMEOUT)

  val readTimeout: Int by option("--read-timeout", help = "Maximum time allowed for reading data (seconds)").int().default(DEFAULT_TIMEOUT)

  val callTimeout: Int by option(
    "--call-timeout",
    help = "Maximum time allowed for the entire call (seconds)",
  ).int().default(DEFAULT_TIMEOUT)

   *
   * The target execution time is implemented on a best-effort basis. If another task in this queue
   * is running when that time is reached, that task is allowed to complete before this task is
   * started. Similarly the task will be delayed if the host lacks compute resources.
   *
   * @throws RejectedExecutionException if the queue is shut down and the task is not cancelable.
   */

Socket writes are guarded by the Http2Writer. Only one stream can write at a time so that messages are not interleaved. Writes are either made by application-layer threads or the do-stuff-later pool.

### Holding multiple locks

You're allowed to take the Http2Connection lock while holding the Http2Writer lock. But not vice-versa. Because taking the Http2Writer lock can block.

        .writeUtf8(boundary)
        .readByteString()

    private var partCount = 0
    private var closed = false
    private var noMoreParts = false

    /** This is only part that's allowed to read from the underlying source. */
    private var currentPart: PartSource? = null

    @Throws(IOException::class)
    constructor(response: ResponseBody) : this(
      source = response.source(),
      boundary =

DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'

# Collect all arguments for the java command:
#   * DEFAULT_JVM_OPTS, JAVA_OPTS, JAVA_OPTS, and optsEnvironmentVar are not allowed to contain shell fragments,
#     and any embedded shellness will be escaped.
#   * For example: A user cannot expect ${Hostname} to be expanded, as it is an environment variable and will be

    assertEquals(0, client.connectionPool.connectionCount())

    // Force reuse. This appears flaky (30% of the time) even though sessions are reused.
    // javax.net.ssl.SSLHandshakeException: No new session is allowed and no existing
    // session can be resumed
    //
    // Report https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8264944
    // Sessions improvement https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8245576

We use `certificateAuthority(int)` to create certificates that can sign other certificates. The
int specifies how many intermediate certificates are allowed beneath it in the chain.

```java
HeldCertificate rootCertificate = new HeldCertificate.Builder()
    .certificateAuthority(1)
    .build();

HeldCertificate intermediateCertificate = new HeldCertificate.Builder()