don't remove closed connections from the server's accept queue #4245
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In preparation for #3549.
This changes the connection queuing logic on the server side. So far, if the server is falling behind on
Accept
ing new connections, we queue up toprotocol.MaxAcceptQueueSize
connections. Each of these connections has a Go routine watching for the connection to close, and removes this connection from the accept queue if it is closed for any reason.I don't really see any reason to do it that way. First of all, the server should be able to keep with accepting connections, so at best this is an optimization for a corner case. Second, the server might be interested in learning why the connection was closed. It shouldn't make a difference if the connection was closed 1ms before or after it was accepted.
I hope to eventually get rid of the
handleNewConn
goroutine altogether. This will require figuring out what happens to these connections when the server is closed. As of v0.40.0, closing the server doesn't close the associated connections anymore: It's now the application's responsibility to deal with these connections. However, we do need to close the connections that weren't accepted yet, since they weren't passed to the application yet. I suspect the current code has a bug here, I don't see this condition being handled anywhere.