-
Notifications
You must be signed in to change notification settings - Fork 180
RUST-530 Decrement connection count when connection is dropped due to unfinished operation #234
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
Conversation
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.
This looks good to me, so assuming there aren't any issues with the CI run, I'll approve it afterwards
src/cmap/mod.rs
Outdated
@@ -300,6 +300,14 @@ impl ConnectionPoolInner { | |||
} | |||
} | |||
|
|||
async fn dropped(&self, conn: Connection) { |
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.
From looking at the "Connection Monitoring and Pooling Specification" (CMAP), it states that the check_in
method should be in charge of closing connections that are "perished". That spec also defines "perished" to mean a number of conditions, among them "Driver-Side timeout".
Given this, I think we can consolidate this logic into the check_in
method, and simply add another check to the if else
chain there for connections that are still executing. Then we can remove this method and also simplify Connection
's drop
implementation a little bit to just call check_in
if the pool still exists.
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.
fine by me, I am not familiar with the pool logic. feel free to change accordingly. I really just needed this to be fixed and did whatever I needed to do 🙈
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.
@patrickfreed or we merge this, someone smarter than me with the necessary domain knowledge of the driver adds a repro to the testing suit and then makes those optimisations that you mention. the last week with hassling with this in production gave me some serious ocd
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.
I can just go ahead and make those changes now. Just wanted to give you the opportunity to do so if you wished 👍
Apologies about closing this! I was attempting to my local branch with rebased history to |
fixes https://jira.mongodb.org/browse/RUST-530
related to https://jira.mongodb.org/browse/RUST-384
the dropped connections that are rendered useless were basically just forgotten and the connection pool was never notified that it has to consider it gone. so by having a very small pool size limit this quickly renders the entire driver blocked and unable to do anymore DB requests.