-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
refactor(bigquery/storage/managedwriter): augment connection pool #7174
Conversation
This PR adds two references to live code: * a pool reference on ManagedStream * a reference to ManagedStream on pendingWrite The ManagedStream->pool reference is to allow a writer to resolve where to find its associated connection, retries, lookups, etc. The reference on the pendingWrite is primarily in service of retries, particularly when we need to re-enqueue and thus potentially re-resolve what connection is associated with the writer. This PR also moves some of the retry processing code onto the connectionPool in service to that goal. As before, this is new code that isn't yet referenced from existing functionality. This PR also more substantially starts to carve out connection management in the pool, providing a basic connection resolver and eviction capabilities. This initial implementation is primitive, and aligns with our current behavior (single unshared connection per writer). We also add some testing of the mapping behavior to ensure we're consistently updating the map for resolution and eviction. Towards: googleapis#7103
@@ -148,6 +298,68 @@ func (co *connection) getStream(arc *storagepb.BigQueryWrite_AppendRowsClient, f | |||
return co.arc, co.pending, co.err | |||
} | |||
|
|||
// lockingAppend handles a single append request on a connection. | |||
func (c *connection) lockingAppend(pw *pendingWrite) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you planning to remove the lockingAppend
method on both connection
and ManagedStream
on this PR or you are going to remove from ManagedStream
already ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I reach the refactor point where I modify ManagedStream most of the functionality goes away, lockingAppend and other connection-oriented funcs will be removed.
Closing this, taking a slightly different approach now. |
This PR adds two references to live code:
The ManagedStream->pool reference is to allow a writer to resolve where to find its associated connection, retries, lookups, etc.
The reference on the pendingWrite is primarily in service of retries, particularly when we need to re-enqueue and thus potentially re-resolve what connection is associated with the writer. This PR also moves some of the retry processing code onto the connectionPool in service to that goal. As before, this is new code that isn't yet referenced from existing functionality.
This PR also more substantially starts to carve out connection management in the pool, providing a basic connection resolver and eviction capabilities. This initial implementation is primitive, and aligns with our current behavior (single unshared connection per writer).
The existing lockingAppend behavior on ManagedStream is added to the connection abstraction. We do not move appendWithRetries as that should stay with the writer (we may want to retry using a different connection).
We also add some testing of the mapping behavior to ensure we're consistently updating the map for resolution and eviction.
Towards: #7103