* both.
 *
 * Applications may configure OkHttp with an authenticator for origin servers, or proxy servers,
 * or both.
 *
 * ## Authentication Retries
 *
 * If your authentication may be flaky and requires retries you should apply some policy
 * to limit the retries by the class of errors and number of attempts.  To get the number of
 * attempts to the current point use this function.
 *
 * ```java

    private final long retryDelayMs;

    /**
     * Create new RDMA error handler
     *
     * @param statistics statistics tracker
     * @param maxRetries maximum number of retries for recoverable errors
     * @param retryDelayMs delay between retries in milliseconds
     */
    public RdmaErrorHandler(RdmaStatistics statistics, int maxRetries, long retryDelayMs) {
        this.statistics = statistics;
        this.maxRetries = maxRetries;

        final String fullPath = "\\" + loc.getServer() + "\\" + loc.getShare() + loc.getUNCPath();
        final int maxRetries = this.ctx.getConfig().getMaxRequestRetries();
        for (int retries = 1; retries <= maxRetries; retries++) {

            if (rpath != null) {
                rpath.setFullUNCPath(null, null, fullPath);
            }

            try {

  /**
   * Invoked when OkHttp decides whether to retry after a connectivity failure.
   *
   * OkHttp won't retry when it is configured not to:
   *
   *  * If retries are forbidden with [OkHttpClient.retryOnConnectionFailure]. (OkHttp's defaults
   *    permit retries.)
   *  * If OkHttp already attempted to transmit the request body, and [RequestBody.isOneShot] is
   *    true.
   *

          - 9910:3306
        options: >-
          --health-cmd "mysqladmin ping -ugorm -pgorm"
          --health-interval 10s
          --health-start-period 10s
          --health-timeout 5s
          --health-retries 10

    steps:
    - name: Set up Go 1.x
      uses: actions/setup-go@v4
      with:
        go-version: ${{ matrix.go }}

    - name: Check out code into the Go module directory

![Events Diagram](../assets/images/******@****.***)

### Events with Retries and Follow-Ups

OkHttp is resilient and can automatically recover from some connectivity failures. In this case, the `connectFailed()` event is not terminal and not followed by `callFailed()`. Event listeners will receive multiple events of the same type when retries are attempted.

   * resizing the table, as well as populating slots with new Cells.
   * There is no need for a blocking lock; when the lock is not
   * available, threads try other slots (or the base).  During these
   * retries, there is increased contention and reduced locality,
   * which is still better than alternatives.
   *
   * Per-thread hash codes are initialized to random values.
   * Contention and/or table collisions are indicated by failed

 */
package okhttp3.internal.connection

import java.io.IOException
import okhttp3.Address
import okhttp3.HttpUrl

/**
 * Policy on choosing which connection to use for an exchange and any retries that follow. This uses
 * the following strategies:
 *
 *  1. If the current call already has a connection that can satisfy the request it is used. Using

        // Should allow retries up to limit
        assertTrue(state.shouldRetry());

        state.incrementRetry(); // Retry 1
        assertTrue(state.shouldRetry());

        state.incrementRetry(); // Retry 2
        assertTrue(state.shouldRetry());

        state.incrementRetry(); // Retry 3
        assertFalse(state.shouldRetry()); // Max retries reached
    }

    @Test

### Choosing between application and network interceptors

Each interceptor chain has relative merits.

**Application interceptors**

 * Don't need to worry about intermediate responses like redirects and retries.
 * Are always invoked once, even if the HTTP response is served from the cache.
 * Observe the application's original intent. Unconcerned with OkHttp-injected headers like `If-None-Match`.