HTTP/2 Write Timeouts Aren’t Immediate #4455
Comments
|
Executable test case? |
|
@swankjesse no, because this happens only at my office. If I try the same application on the same device at home, the upload is super fast without any timeout or delay (about 500ms each file) |
|
Another info: the same code with a post to a standard HTTP 1.1 server works as expected |
|
Example code at https://gist.github.com/sarbyn/2940cb5a5f4c6c144410f3dd7569fdfe |
|
@sarbyn, can you set this on Also, does this reproduce with http://www.nghttp2.org/httpbin/post? |
|
This is the output with LoggingEventListener enabled |
looks suspicious. The fact that at 10:12:17.714, the monitor was held by SSL_write() for 7.440s, means that it was taken at 10:12:10.274, which is 5.025s after starting to write the request body. Both this and the stack trace of the SocketTimeoutException indicate that the 5s write timeout kicked in and blocked on writing the RST_STREAM frame. Even if there was no write timeout, it would have been the call timeout blocked on writing the RST_STREAM frame, preventing the call from ending after exactly 10 seconds as you expect. This can also explain why it happens only with HTTP/2, as with HTTP/1.1 the socket is simply closed when the timeout fires and there is no attempt to write anything, which may block. I'm not sure if this is an actual issue. I expect that if you remove the write timeout and add some logging, you'll see that the call timeout in fact kicks in after 10 seconds, but just takes a few extra seconds to completely end the call. |
|
The last log is from an android application with AsyncTask but happens also with the Gist provided in the link above. For example look at the log below (Read/write timeout 5 seconds - callTimeout 10 seconds). The socket timeout is fired afted 17 seconds: Another strange things: this is the upload result, (same laptop, same network, same server, same list of file), of a python script: This is the result with OkHTTP (Read/write timeout 5 seconds - callTimeout 10 seconds) 45 seconds vs 117 😞 |
|
I think the core problem is that our HTTP/2 write timeouts don’t have teeth. On HTTP/1 we close the underlying socket which takes effect immediately. On HTTP/2 we cancel the stream, but if it’s currently blocked on a write it won’t cancel until that write returns. |
swankjesse
changed the title
|
Any news on this? |
|
@gabrielpopa sadly none! |
Related to #1902, should we be interrupting ourselves? |
|
Perhaps! |
|
Related to issue #3278 because timeouts were supposed to save us from the hang if they really were effective. |
|
Are there any updates? I have the exact same issue in an app in case of really bad network quality. The stream seems to be blocked in |
|
@gorogaron no updates right now. We might have to do something awkward, like failing the entire connection if any write times out. |
|
Is there any plan to fix this? Here is my scenario
Whats the best way to workaround this situation?
|
|
|
Viadao |
|
Okhttp 3.x isn't supported. Can you reproduce with 4.11? Thanks |
|
|
|
|
No repro on 4.x |
|
@yschimke Could you please tell me which pull request solved this issue? I have encountered the same problem while using 3.x and I want to learn about how the issue has been fixed. Thanks a lot! |
|
It's a bug raised against 3.x. There is no action to take without a reproduction using 4.x. Do you get it still with 4.12? |
|
@yschimke No, I got it with 3.x. I just want to know what code changes have been made in order to solve this issue |
EXPECTED:
ACTUAL:
Seven uploads exceeded the callTimeout and goes in error.
I can reproduce this behaviour easily but this happens only here at my office, so an example code could be useless
The text was updated successfully, but these errors were encountered: