Why OKHttp is designed as not to retry when SocketTimeoutException

Viewed 1211
private boolean isRecoverable(IOException e, boolean requestSendStarted) {
    ....
    // If there was an interruption don't recover, but if there was a 
    //timeout connecting to a route
    // we should try the next route (if there is one).
     if (e instanceof InterruptedIOException) {
      return e instanceof SocketTimeoutException && !requestSendStarted;
    }
   ....
    return true;
}

Here is the code snippet in RetryAndFollowUpInterceptor in OKHttp.

My question is why OkHttp not retry when SocketTimeoutException and requestSendStarted == true?

Because I think if there are some other routers, we can retry another ip or router

2 Answers

Consider the case where a request was successfully sent and the problem occurred when response data was transmitted to the client. Automatic retry in this case may make the server to repeat some action (increasing some count, writing a record somewhere) which may be undesirable. OKHttp lets the user to decide what to do in this case.

The goal was to retry if OkHttp couldn’t connect at all. If the server was reachable, but just responded slowly, then it’s just as likely to be an application-layer problem where retrying won’t help.

Related