*
     * <p>Note that the method will be called even upon an invocation of {@code tryLock()}. Although
     * {@code tryLock()} technically recovers from deadlock by eventually timing out, this behavior
     * is chosen based on the assumption that it is the application's wish to prohibit any cyclical
     * lock acquisitions.
     */
    void handlePotentialDeadlock(PotentialDeadlockException exception);

      addTests(
          suite,
          method,
          Scenario.UNSATISFIED_AND_INTERRUPTED_BEFORE_WAITING,
          TimeoutsToUse.PAST,
          // prefer responding to interrupt over timing out
          isInterruptible(method) ? Outcome.INTERRUPT : Outcome.FAILURE);
      addTests(
          suite,
          method,
          Scenario.UNSATISFIED_AND_INTERRUPTED_BEFORE_WAITING,

    assertThat(startupTimes.get(a)).isAtLeast(150);
    // Service b startup takes at least 353 millis, but starting the timer is delayed by at least
    // 150 milliseconds. so in a perfect world the timing would be 353-150=203ms, but since either
    // of our sleep calls can be arbitrarily delayed we should just assert that there is a time
    // recorded.
    assertThat(startupTimes.get(b)).isNotNull();
  }

   * <p>This executor is appropriate for tasks that are lightweight and not deeply chained.
   * Inappropriate {@code directExecutor} usage can cause problems, and these problems can be
   * difficult to reproduce because they depend on timing. For example:
   *
   * <ul>
   *   <li>When a {@code ListenableFuture} listener is registered to run under {@code
   *       directExecutor}, the listener can execute in any of three possible threads:
   *       <ol>

    }

    /**
     * Creates a QueryResponseList containing the search results and metadata.
     * Wraps the document list with additional information about the search operation
     * including record counts, timing, and pagination details.
     *
     * @param documentList the list of search result documents
     * @param allRecordCount the total number of records found

	isReadLock := true
	return dm.lockBlocking(ctx, cancel, id, source, isReadLock, opts)
}

// lockBlocking will try to acquire either a read or a write lock
//
// The function will loop using a built-in timing randomized back-off
// algorithm until either the lock is acquired successfully or more
// time has elapsed than the timeout value.

- Use proper authentication header:
  ```bash
  curl -u admin:admin ...
  # or
  curl -H "Authorization: Basic YWRtaW46YWRtaW4=" ...
  ```

#### Issue: Large bulk imports timing out

**Solution**:
- Split large files into smaller batches (e.g., 10,000 docs per file)
- Increase timeout in `system.properties`:
  ```properties
  crawler.document.request.timeout=600000
  ```

   * which serves a fixed sequence of responses from a [queue][enqueue].
   *
   * Other dispatchers can be configured. They can vary the response based on timing or the content
   * of the request.
   */
  public var dispatcher: Dispatcher = QueueDispatcher()

  public val socketAddress: InetSocketAddress
    get() = socketAddress_ ?: error("call start() first")

    dropped these cipher suite.

## Version 2.5.0

_2015-08-25_

 *  **Timeouts now default to 10 seconds.** Previously we defaulted to never
    timing out, and that was a lousy policy. If establishing a connection,
    reading the next byte from a connection, or writing the next byte to a
    connection takes more than 10 seconds to complete, you’ll need to adjust

    val requestBodyDelay = 250L
    val responseHeadersStartDelay = 250L
    val responseBodyStartDelay = 250L
    val responseBodyEndDelay = 250L

    // Warm up the client so the timing part of the test gets a pooled connection.
    server.enqueue(MockResponse())
    val warmUpCall =
      client.newCallWithListener(
        Request
          .Builder()
          .url(server.url("/"))