list.eventsSkipped.Add(int64(len(list.queue)))
		return
	default:
		list.eventsSkipped.Add(1)
		err := fmt.Errorf("concurrent target notifications exceeded %d, configured notification target is too slow to accept events for the incoming request rate", maxConcurrentAsyncSend)
		for id := range targetIDset {
			reqInfo := &logger.ReqInfo{}
			reqInfo.AppendTags("targetID", id.String())

   * the capacity, it is doubled in size unless some other thread
   * holds the lock. If a hashed slot is empty, and lock is
   * available, a new Cell is created. Otherwise, if the slot
   * exists, a CAS is tried.  Retries proceed by "double hashing",
   * using a secondary hash (Marsaglia XorShift) to try to find a
   * free slot.
   *
   * The table size is capped because, when there are more threads

	}
	cfg.ListQuorum = listQuorum

	replicationPriority := env.Get(EnvAPIReplicationPriority, kvs.GetWithDefault(apiReplicationPriority, DefaultKVS))
	switch replicationPriority {
	case "slow", "fast", "auto":
	default:
		return cfg, fmt.Errorf("invalid value %v for replication_priority", replicationPriority)
	}
	cfg.ReplicationPriority = replicationPriority

        localhostIpv6,
      )

    client =
      clientTestRule.newClientBuilder()
        .eventListenerFactory(clientTestRule.wrap(listener))
        .connectTimeout(60, TimeUnit.SECONDS) // Deliberately exacerbate slow fallbacks.
        .dns { dnsResults }
        .fastFallback(true)
        .build()
    url =
      serverIpv4.url("/")
        .newBuilder()
        .host("localhost")
        .build()
  }

        blocker = (Blocker) state;
      }
      spinCount++;
      if (spinCount > MAX_BUSY_WAIT_SPINS) {
        /*
         * If we have spun a lot, just park ourselves. This will save CPU while we wait for a slow
         * interrupting thread. In theory, interruptTask() should be very fast, but due to
         * InterruptibleChannel and JavaLangAccess.blockedOn(Thread, Interruptible), it isn't

   *       </ol>
   *       Given all these possibilities, it is frequently possible for listeners to execute in UI
   *       threads, RPC network threads, or other latency-sensitive threads. In those cases, slow
   *       listeners can harm responsiveness, slow the system as a whole, or worse. (See also the
   *       note about locking below.)
   *   <li>If many tasks will be triggered by the same event, one heavyweight task may delay other

   * this address.
   *
   * If [planToReplace] is non-null, this will swap it for a pooled connection if that pooled
   * connection uses HTTP/2. That results in fewer sockets overall and thus fewer TCP slow starts.
   */
  internal fun planReusePooledConnection(
    planToReplace: ConnectPlan? = null,
    routes: List<Route>? = null,
  ): ReusePlan? {
    val result =

 * Each response body is backed by a limited resource like a socket (live network responses) or
 * an open file (for cached responses). Failing to close the response body will leak resources and
 * may ultimately cause the application to slow down or crash.
 *
 * Both this class and [Response] implement [Closeable]. Closing a response simply
 * closes its response body. If you invoke [Call.execute] or implement [Callback.onResponse] you

    try {
      // if waiting works, this should get stuck
      Queues.drain(q, newArrayList(), 1, MAX_VALUE, NANOSECONDS);
      fail();
    } catch (InterruptedException expected) {
      // we indeed waited; a slow thread had enough time to interrupt us
    }
  }

  // same as above; uninterruptible version
  @SuppressWarnings("ThreadPriorityCheck") // TODO: b/175898629 - Consider onSpinWait.

   * corresponding response body stream. This is necessary if we want servers to be able to stop
   * inbound data and send an early 400 before the request body completes.
   *
   * This test sends a slow request that is canceled by the server. It expects the response to still
   * be readable after the request stream is canceled.
   */
  @Disabled
  @Test
  fun serverCancelsRequestBodyAndSendsResponseBody() {