Infinite Retry happening (No cap on Okhttp retry count) #7530
Comments
|
Can you attach a printing event listener and record the output. Its should show what's happening with connections? It's hard to investigate from bug report without a repro test cade to run. |
|
@yschimke, We are using OkHttp Version: 4.9.3 (I checked the latest version as well, I found the same behaviour). These are Logs of EventListeners:
These are the logs we receive at NetworkInterceptor (We are receiving exception so all the details of exception is here):
|
|
That log isn't much help without details like the dns results. It's probably retrying on multiple hosts returned by dns. You can disable retry on connection failures on the client if so. But its hard to guess from the big report. |
|
@yschimke please check these logs |
|
In RetryAndFollowUpInterceptor, we are getting this error response in 2nd catch block |
|
It definitely shouldn't be retrying infinitely, it clearly is because of Separately from that, while testing with Charles, you can set a callTimeout of 80 seconds that should stop the request, or retryOnConnectionFailure = false. I'll take a look at why that is. |
|
Yeap this happens to me as well, I have multiple instances of my backend server running so dnsEnd returns 4 addresses and the endpoint times out but the client keeps trying all the different IPs even if I have set .retryOnConnectionFailure(false) Any ideas? Any older version that was working to downgrade? |
|
@Yogesh-1206 also I am noticing that even if all 4 retries are getting timed out one or two of them actually reaching the backend so I am assuming the TCP connection to the current target is not properly terminated when you go and try the next server in the list |
|
I tried to make a repro on 5.x without any luck. The charles server and the proxy are different though. Before I start manually testing, can you provide additional information such as the exact OkHttp you are using? |
|
OkHttp Version: 4.9.3 |
|
OK, can reproduce something sort of like this on 4.10. But my repro only causes a second follow up, but it's definitely possible that the proxy plus other traffic is causing the connection to stay healthy and get retried continually. It might be worth trying to 5.0.0-alpha.10, while I continue to investigate. I'd like to confirm against 5.0.0-alpha.10, before deciding any changes. |
|
OK, my test with 5.x, is also using happy eyeballs ( |
|
I confirmed this case, I don't think RealConnection.trackFailure will avoid this. I'm going to continue this in #7588 |
|
thanks @yschimke for reaching back. So in order to get this right does it make sense to try using 5.0.0-alpha.10 or not? |
|
Please try against 5.0.0-alpha11, it should have fast fallback enabled and I hope it solves this. But there is still an underlying issue I'm working through from the bottom up, putting tests in place first. If we can eventually reproduce your exact situation in https://github.com/square/okhttp/blob/ebb6e92d93f1725eacfd12b6b1afec95b4f704e9/okhttp/src/jvmTest/java/okhttp3/RouteFailureTest.kt we can make sure it's fixed. But I'm not sure if it will be easy to backport. |
We are seeing infinite retries in OkHttp client (RetryAndFollowUpInterceptor).
I performed a Post Api request with connect, write and read timeout of 70 seconds. I used Charles to block the request so that it will not able to hit the server. I am expecting a SocketTimeoutException if I am blocking a request for greater than 70 sec, but I am getting Stream Reset Exception even before 70 sec (around 60 sec).
I am getting this error for the request:
at Charles I am seeing: Socket: Connection or outbound has closed
and at App Side: okhttp3.internal.http2.StreamResetException: stream was reset: REFUSED_STREAM
After getting this error at RetryAndFollowUpInterceptor, it again retries and this will continue infinitely (request is blocked at Charles)
Note: I tried many Api’s for finding this behaviour, but I found only one API.
Is there any solution to this problem?, if not then there should be some retryCount at OkHttp level where this kind of behaviour can be eliminated.
The text was updated successfully, but these errors were encountered: