goroutine 23888 - waiting for rlock - did not do ioutil.ReadAll() yet
goroutine 23939 - waiting for rlock - did not do ioutil.ReadAll() yet
goroutine 24018 - waiting for rlock - did not do ioutil.ReadAll() yet
goroutine 34 - waiting for r/w lock
My understanding is that since RWMutex is writer-preferring, 34 will not acquire the r/w lock until 23751 and 23781 finish, and will also prevent 24018, 23939 and 23888 from acquiring the read lock.
Now I'm wondering whether having 3 requests that are not reading request bodies immediately (because they have not acquired the shared lock) could prevent the other 2 requests that already have the shared lock from making progress, in particular due to the fact that request bodies are rather large ~20MB in size each.
In other words - does HTTP/2 require all request handlers to read request bodies to ensure liveness? It appears that HTTP/1.1 server does not have this behavior (I'm guessing because there is no request pipelining).
What version of Go are you using (
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
Linux Mint (client)
What did you do?
This was reported by users of Kopia (backup tool). I can't personally reproduce this, but two users have reported it independently.
There's a client and server (HTTP+TLS), both compiled using golang 1.14.7. The client sends large blobs (~20 MB) to the server using PUT method on 1-4 parallel goroutines.
Sometimes the server gets stuck handling requests for no apparent reason. We have captured stack traces when this happens, both client and server-side:
(server) kopia/kopia#538 (comment)
(client) kopia/kopia#538 (comment)
In the stack traces you see that the server is stuck on ioutil.ReadAll() when reading from the request body for 3 minutes:
Server-side code is here:
Client-side code is here:
According to the bug report, disabling HTTP/2 using
GODEBUGresolves the issue.
Full disclosure: I'm a Googler, but Kopia is my personal project and not affiliated with Google.
The text was updated successfully, but these errors were encountered: