-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: Connection reset incorrectly in high load performance test #26956
Comments
Got a repro? |
/cc @fraenkel |
I have tried a variety of things with h2load as the client and a server that returns 100 - 16k bytes of data in the response. I have not been able to cause any connection reset issue regardless of debug on the server side to cause significant slow downs. |
hi Fraenkel, This issue can be reproduced easily if add sc.logf() between code1 and code2 in lower load performace test. B.R |
@crowfrog I have added sc.logf() in multiple places between your code1 and code2 blocks. I still don't hit any error when driving with h2load. I have also tried with and without debug to slow things down but that too doesn't cause any error. |
@fraenkel Does 7150 req/s belong to one connections to golang http2 server? Does the 7150 response/s have some contant in body? |
@crowfrog Yes. There were over 10k streams created. I tried smallish and larger payloads but all constant sizes. |
What version of Go are you using (
go version
)?golang:1.10.0 linux
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?container: rhel
kubenet:
What did you do?
In some cases, the server goroutine will be switch out execution context between code1 and code2.
If the handler goroutine switch back to execution context in these cases, that will make writeDataFromHandler() (writeHeaders() also?) failed and set responseWriterState to dirty.
This issue can be reproduced easily if add sc.logf() between code1 and code2 in lower load performace test.
PS: I think in wroteFrame(), we shouldn'd call "wr.replyToWriter(res.err)" when closing stream with error. It will cause writeDataFromHandler() exit with no error. But in fact this stream/responseWriterState is already on incorrect status.
What did you expect to see?
no connection reset in load test
What did you see instead?
connecttion reset and traffic failed beofre new connection set up
The text was updated successfully, but these errors were encountered: