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.
I'm opening this PR to spark some discussion. This code is WIP, it lacks tests and proper flow, however functional.
Here's a small summary of how the http/2 connection pooling works in Go, as far as I understand:
You can browse the code here. Instead of writing a custom connection pool, I'm exploiting reflection here to trigger the 4th step.
First,
CloseIdleConnections
can be called to initialize the transport's internal connection pool, as seen here.The function that checks if a connection is available is here. The most practical field to change in order to mark a connection as unavailable is
closed
. After retrieving and locking appropriate mutexes on both pool and connection level, theclosed
flag for all connections is set totrue
.Following our scenario, the next connection request reaches step 4 since there are no "available" connections (although they are alive and well). Internals create a new connection, and add it to the pool. Since the resulting connection is obtained manually via
GetClientConn
, the returned connection can be pinged periodically in a separate goroutine.Once the deed is done,
closed
flags for all connections in the pool are restored. Since dropped connections are cleaned automatically from the pool, when pinging fails, the desired connection amount can be sustained viaaddNewConn
.Reflected fields seem stable, they haven't been changed in 2 years. Since it is not executing on a hot path, reflect performance is not much of a concern.
Thoughts? Is it worth fleshing out, or would you be against a reflection based solution?