-
Notifications
You must be signed in to change notification settings - Fork 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
write: broken pipe in func (r Data) Render #1089
Comments
Hi @deepch I don't reproduce it, I use the |
im use golang 1.9 r
http: panic serving - I think it happens when the client saves the file and interrupts the download or tears up the connection with the client. (I've just removed this (panic) message from you in the code. http: TLS handshake error from - this is a bug on git golang there you need to replace logger |
|
*wdata = 10MB data buffer write: broken pipe context.go:626 it no panic if regular please delete panic broken pipe == client close socket add test c.Data(200, "video/MP2T", *wdata) 963acc4#diff-aece76ea64cacf005bef81b966af51d3 old no problem
new
if client close connection it not panic |
I wanted to follow up on this ticket, because it touches on something I have been encountering and I wanted clarification. I am seeing a Recovery panic dump like this when the client breaks there connection and the the 'broken pipe' results in Gin wanting to set a 500 status code. But it can't because the request had already started, so we see an error saying the status was trying to be changed after it had already been written. Is it expected that we should be seeing this huge trace dump in this case? Should the recovery handler try and check for a broken pipe before trying to set a 500 status? See: https://github.com/gin-gonic/gin/blob/master/recovery.go#L43 |
I don't see why borken pipe need to set 500 status. The response is not gonna received by client anyway. |
@wwjue, exactly. But its indiscriminately setting that status for any panic recovery. It shouldn't be appropriate for broken pipes though. |
I see this a lot when running timed load tests with wrk (https://github.com/wg/wrk) - Once the load test hits the time limit, wrk closes any inflight requests and I get a big pile of panic recovery stack traces complaining about closed sockets. In my case, a closed socket is not catastrophic and shouldn't trigger a panic - can we get a configurable perhaps that allows us to downgrade this from a panic? For example, I'm doing a 1 minute load test, 500 open connections at a time, on a gin microservice using this commandline:
|
@LeftyBC, I also see this all the time when I use |
Friendly bump as we're also being affected by this issue. |
#1259 already merged, thanks! |
i test gopkg.in/gin-gonic/gin.v1 and github.com/gin-gonic/gin
i disable log
and my log
How can I turn off these errors. ?
write: broken pipe - The client interrupted the download of the file and I do not see this as an error.
http: TLS handshake error - I, too, would not want to see this.
The text was updated successfully, but these errors were encountered: