Skip to content

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

Closed
wants to merge 0 commits into from

Conversation

extrawurst
Copy link

@extrawurst extrawurst commented Aug 13, 2020

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.

Copy link
Contributor

@saghm saghm left a 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

@saghm saghm changed the title notify pool that a connection dropped RUST-530 Decrement connection count when connection is dropped due to unfinished operation Aug 17, 2020
src/cmap/mod.rs Outdated
@@ -300,6 +300,14 @@ impl ConnectionPoolInner {
}
}

async fn dropped(&self, conn: Connection) {
Copy link
Contributor

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.

Copy link
Author

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 🙈

Copy link
Author

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

Copy link
Contributor

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 👍

@saghm
Copy link
Contributor

saghm commented Aug 18, 2020

Apologies about closing this! I was attempting to my local branch with rebased history to extrawurst/master, but I accidentally overwrote it with my local master instead of my local branch, which Github apparently interpreted as a request to close the PR, which now prevents me from pushing to the fork again. Since we're trying to get a release out tonight with this fix, I pushed the changes manually to Github; you can see extrawurst's commit here and Patrick's follow-up here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants