-
-
Notifications
You must be signed in to change notification settings - Fork 89
Re-instate minimum connections after failed connection #612
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
base: main
Are you sure you want to change the base?
Re-instate minimum connections after failed connection #612
Conversation
…we are below the minimum connection count
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #612 +/- ##
==========================================
+ Coverage 75.88% 75.99% +0.10%
==========================================
Files 134 134
Lines 10098 10135 +37
==========================================
+ Hits 7663 7702 +39
+ Misses 2435 2433 -2
🚀 New features to boost your workflow:
|
| let leaseResult = self.connections.leaseConnection(at: index, streams: UInt16(requests.count)) | ||
| let connectionsRequired: Int | ||
| if requests.count <= self.connections.stats.availableStreams + self.connections.stats.leasedStreams { | ||
| connectionsRequired = self.configuration.minimumConnectionCount - Int(self.connections.stats.active) |
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.
Does active include already connecting?
| ) -> Action { | ||
| // this connection was busy before | ||
| let requests = self.requestQueue.pop(max: availableContext.info.availableStreams) | ||
| if !requests.isEmpty { |
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.
what happens, if we have min connections = 5, but are coming out of circuit breaker and don't have anything in the queue?
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.
oh this handled down below, once we have checked the pool state.
| cancelledTimers: TinyFastSequence<TimerCancellationToken>, | ||
| scheduledTimers: Max2Sequence<Timer> | ||
| ) -> ConnectionAction? { | ||
| if connectionCount > 0, |
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.
lets use a guard here, instead.
If a connection fails then only that connection is allowed to retry to connect. All other connections on failure will be removed. This leads us to the situation where if we return to the running state from the failed connection state we could have a large request queue being served by only the one successful connection.
This PR ensures at least the minimum number of connections are created on returning to the running state. On top of this if the number of requests is greater than the number of streams a new connection will be created.