Stuck on an issue?
Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
HTTP/2 Write Timeouts Aren’t Immediate
See original GitHub issue- OkHttp 3.12.0
- Android asynctask that sends a set of little file (about 1.3mb each file) via HTTP2 POST to a cloud service, one by one
- Android device with Android 5.1.1. (API LEVEL 22)
- HttpClient build as following:
val client = OkHttpClient.Builder()
.addInterceptor(logging)
.connectTimeout(120, TimeUnit.SECONDS)
.readTimeout(5000, TimeUnit.MILLISECONDS)
.writeTimeout(5000, TimeUnit.MILLISECONDS)
.callTimeout(10000, TimeUnit.MILLISECONDS)
.build()
- this is the async task code
fun uploadFile(fileName: String, fileInputStream: InputStream, totalNumber: Int, index: Int) {
val client = OkHttpClient.Builder()
.connectTimeout(120, TimeUnit.SECONDS)
.readTimeout(5000, TimeUnit.MILLISECONDS)
.writeTimeout(5000, TimeUnit.MILLISECONDS)
.callTimeout(10000, TimeUnit.MILLISECONDS)
.build()
val data = fileInputStream.readBytes()
Timber.i("Start uploading $fileName (${data.size} bytes)")
val digest = md5(data)
val body = RequestBody.create(null, data)
val request = Request.Builder()
.addHeader(HEADER_CHECKSUM, digest)
.url(url)
.post(body)
.build()
try {
val call = client.newCall(request)
call.execute().use { response ->
/* do nothing */
}
} catch (e : Exception) {
Timber.i(e)
}
}
- At my offiche I have a very bad network condition with a lot of TCP retransmission
EXPECTED:
- The maximum expected time for each file (callTimeout) should be 10 seconds ACTUAL:
- these are for example the timing for 10 file:
- 85622ms - UPLOAD ERROR
- 8539ms - UPLOAD ERROR
- 18381ms - UPLOAD ERROR
- 8564ms - UPLOAD ERROR
- 10100ms - UPLOAD ERROR
- 6810ms
- 61457ms - UPLOAD ERROR
- 9088ms
- 8040ms
- 22351ms - UPLOAD ERROR
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
Issue Analytics
- State:
- Created 5 years ago
- Comments:22 (5 by maintainers)
Top Results From Across the Web
Why Turning on HTTP/2 Was a Mistake - Lucidchart
HTTP/2 is a great leap forward for HTTP, but turning it on HTTP/2 was a mistake. ... so responses to requests were delayed...
Read more >Chapter 7. Advanced HTTP/2 concepts - HTTP/2 in Action
An HTTP/2 stream is created for a single download and then discarded. This is one reason why HTTP/2 streams aren't exact analogs for...
Read more >Timeouts, retries and backoff with jitter - Amazon AWS
The preferred solution that we use in Amazon is a backoff. Instead of retrying immediately and aggressively, the client waits some amount of...
Read more >The complete guide to Go net/http timeouts
When writing an HTTP server or client in Go, timeouts are amongst the ... is HTTPS, SetWriteDeadline is called immediately after Accept so ......
Read more >How to dispatch a Redux action with a timeout? - Stack Overflow
Writing Async Code Inline. This is by far the simplest way. And there's nothing specific to Redux here. store.dispatch({ type: ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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.
This is the output with LoggingEventListener enabled