-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/net/http2: stream was reset: PROTOCOL_ERROR #31534
Comments
Can you run the Minio server with |
Log :
|
@sinhaashish Next time please give us exact steps to reproduce the issue. The code above is incomplete and knowing to use the 6.0.5 version was not very obvious. |
@fraenkel : Can you try it a multiple of times, as the issue is sporadic for me too. |
@sinhaashish I have reproduced the issue. I am still determining the root cause. There are multiple issues going on here which is why it will take some time. I see cases where the client side is reusing a closed stream and the server eventually says to GOAWAY. I will let you know more as I dig deeper. |
Working backwards, the crazy looping looks like a minio issue which I have no plans to debug. The call stack is about 45 calls deep and the majority is minio and gorilla. Most of the threads are stuck waiting to read data from the body. This is when the number of concurrent requests is exceeded. Other times, I see minio also stuck trying to grab locks during PutObject. This too is not something I will debug. The only remaining investigation is the very first issue that occurs. |
The very first error that occurs looks like a client initiated issue.
After the new connection is established, we then run into the issues listed above. So far I don't see anything that points to an issue on the server side. Someone needs to investigate the client issue first. |
What does it mean by client initiated issue ? Are you saying okhttp is buggy here ? |
I can only tell you what I see. Someone would have to debug the client side to see what is going on. |
Can you tell me exactly what that might be? - @fraenkel would like to share this with okhttp project? |
@fraenkel in this scenario the cause is HTTP 2.0 failing with HTTP 1.1 we don't see these issues at all. NOTE: nodes are also communicating over HTTP 2.0 with TLS connections as well as clients. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I am using minio for Object storage. Minio is a golang project using go1.12 as the base go version.
The server is HTTP2 enabled. I use using minio java client which uses
okhttp3
. when i try to store the object in a bucket in multi threaded mode i getokhttp3.internal.http2.StreamResetException: stream was reset: NO_ERROR
.Refer minio/minio#7501 .
okhttp3.OkHttpClient
uses http2.0 by default which causes such issue.If i forcefuly set the protocol to 1.1 ,it works fine.
Refer PR minio/minio-java#766.
I find there is some issue with
Go1.12
orokhttp3
as i found this issue in the community.Refer square/okhttp#3955
The only solution provided there was to revert to HTTP1_1 .
Setting the protocol to 1.1 is not the solution as i am not using the functionality of HTTP2.0 enabled server.
Raised the issue with
okhhttp
refer square/okhttp#4964Below is the code which replicates the problem
What did you expect to see?
Object should have been uploaded.
What did you see instead?
okhttp3.internal.http2.StreamResetException: stream was reset: PROTOCOL_ERROR
The text was updated successfully, but these errors were encountered: