Skip to content
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

Add timeout to writing to responses #15831

Merged

Conversation

zeripath
Copy link
Contributor

In #15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix #15826

Signed-off-by: Andrew Thornton art27@cantab.net

In go-gitea#15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix go-gitea#15826

Signed-off-by: Andrew Thornton <art27@cantab.net>
@@ -250,6 +253,13 @@ type wrappedConn struct {
closed *int32
}

func (w wrappedConn) Write(p []byte) (n int, err error) {
if PerWriteWriteTimeout > 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why check? It's a const value, isn't it?

Copy link
Contributor Author

@zeripath zeripath May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A const that is labelled so that you can change it at compile time to something else...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

e.g.

LDFLAGS="-X \"code.gitea.io/gitea/modules/graceful.PerWriteWriteTimeout=0\""

or

LDFLAGS="-X \"code.gitea.io/gitea/modules/graceful.PerWriteWriteTimeout=1s\""

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label May 11, 2021
@6543
Copy link
Member

6543 commented May 11, 2021

This will break some large repo views, who need long time on first view ..., it could be used temporarly until we can render multithreaded again!

@zeripath
Copy link
Contributor Author

This will break some large repo views, who need long time on first view ..., it could be used temporarly until we can render multithreaded again!

No it won't

This is at the time of writing.

@zeripath
Copy link
Contributor Author

it could be used temporarly until we can render multithreaded again!

This is an orthogonal issue to the render multithreaded issue - the singlethreading through the render has revealed that it exists but the problem is still a real issue.

@zeripath zeripath mentioned this pull request May 12, 2021
2 tasks
Copy link
Member

@noerw noerw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For other reviewers: This is not a timeout on TCP connections between devices.
This is (at least on unix systems) a timeout the kernel sets on the connection when writes to the network interface are blocked for whatever reason.

edit: this is a stopgap to #15826, but isn't a fix to the underlying issue. I think we should keep that issue open until we got more feedback

@@ -28,6 +28,9 @@ var (
DefaultMaxHeaderBytes int
)

// PerWriteWriteTimeout timeout for writes
const PerWriteWriteTimeout = 5 * time.Second
Copy link
Member

@noerw noerw May 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5 secs seem a lot; if kernel blocks for that duration the system has bigger problems..
200ms seems to be a lower bound due to write batching with NAGLE (?), I'd go with 500ms?
But as a stopgap to avoid lingering connections a large value seems ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I picked 5s as value everyone could agree meant that the underlying connection is totally blocked and just wasn't coming back. But I have no metric to know what is a good value here as I don't completely understand the situations where this happens.

I'm suspecting that the problem is due to some network reconfiguration that leads to the connection at the go end being disconnected from the client but somehow didn't kill the connection.

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels May 13, 2021
@zeripath
Copy link
Contributor Author

I suspect it's not actually a stop gap. I think this is a genuine thing - If you don't set a writetimeout go will happily sit there trying to write to a blocked connection indefinitely. Given we have situations like docker, Unix pipes, fcgi, bsds, logrotating proxy servers and so on. I think there are plenty of ways that this could happen. Imagine a situation whereby your network goes down - is the connection closed? It's not really - but the buffer can fill up and then you get write blocking. If you don't have a timeout you never know.

It could be that gitea is being told by the system that something is happening - eg through a signal but we're capturing it and ignoring it because we weren't expecting it. I dunno but I think this has been affecting a few people for a while.

@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels May 13, 2021
@zeripath
Copy link
Contributor Author

make lgtm work

@zeripath zeripath merged commit 1a56599 into go-gitea:main May 14, 2021
@zeripath zeripath deleted the fix-15826-timeout-writing-to-responses branch May 14, 2021 12:44
zeripath added a commit to zeripath/gitea that referenced this pull request May 14, 2021
Backport go-gitea#15831

In go-gitea#15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix go-gitea#15826

Signed-off-by: Andrew Thornton <art27@cantab.net>
@zeripath zeripath added the backport/done All backports for this PR have been created label May 14, 2021
zeripath added a commit that referenced this pull request May 14, 2021
Backport #15831

In #15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix #15826

Signed-off-by: Andrew Thornton <art27@cantab.net>
AbdulrhmnGhanem pushed a commit to kitspace/gitea that referenced this pull request Aug 10, 2021
In go-gitea#15826 it has become apparent that there are a few occasions when a response can
hang during writing, and because there is no timeout go will happily just block
interminably. This PR adds a fixed 5 second timeout to all writes to a connection.

Fix go-gitea#15826

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Oct 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backport/done All backports for this PR have been created lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Gitea stops responding on HTTP
5 participants