net/http: Post http://example.com: net/http: HTTP/1 transport connection broken: readLoopPeekFailLocked: EOF #15446
Labels
Milestone
Comments
|
Thanks for the report. I think this should be fixable with the information provided. |
|
@bradfitz Is this fixed on master? |
|
Not yet. This bug is still open. Commits will be referenced from here. |
|
CL https://golang.org/cl/23160 mentions this issue. |
|
CL https://golang.org/cl/25153 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Jul 26, 2016
… failure From at least Go 1.4 to Go 1.6, Transport.RoundTrip would return the error value from net.Conn.Read directly when the initial Read (1 byte Peek) failed while reading the HTTP response, if a request was outstanding. While never a documented or tested promise, Go 1.7 changed the behavior (starting at https://golang.org/cl/23160). This restores the old behavior and adds a test (but no documentation promises yet) while keeping the fix for spammy logging reported in #15446. This looks larger than it is: it just changes errServerClosedConn from a variable to a type, where the type preserves the underlying net.Conn.Read error, for unwrapping later in Transport.RoundTrip. Fixes #16465 Change-Id: I6fa018991221e93c0cfe3e4129cb168fbd98bd27 Reviewed-on: https://go-review.googlesource.com/25153 Reviewed-by: Andrew Gerrand <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Run-TryBot: Brad Fitzpatrick <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
go version)?go env)?Send HTTP POST requests to a host that seems to close the connection some specific time after the response. We see the error
Post http://example.com: net/http: HTTP/1 transport connection broken: readLoopPeekFailLocked: EOFmultiple times per second when doing around 100 requests per second.It's hard to debug on live traffic and I haven't been able to reproduce this in a clean example.
The error seems to come from
roundTrip()which means the request is already in flight. But it also comes fromreadLoopPeekFailLocked()which is called fromreadLoop()in the case of no expected responses.I'm guessing the connection is closed after a request. Because
pc.readLoopPeekFailLocked(err)is called aftererris wrapped in abeforeRespHeaderError{err}thepeekErr == io.EOFinreadLoopPeekFailLocked()is false and the error gets assigned topc.closedwhile the connection is already in use. After that I'm not sure, the connection must have somehow already been chosen for the next request. Otherwise it wouldn't make sense thatpc.numExpectedResponses == 0while we are inside the loop to wait for a response.Is there any debugging (logging things) I can do on the live traffic to help find this bug?
The text was updated successfully, but these errors were encountered: