Add maxUses config option to Pool#2157
Merged
brianc merged 1 commit intobrianc:masterfrom Apr 9, 2020
Merged
Conversation
brianc
approved these changes
Apr 9, 2020
Owner
brianc
left a comment
brianc
left a comment
There was a problem hiding this comment.
Amazing work! Thank you so much! This diff is much easier to review which is cool. Also, I love that you added documentation for this feature. I'll ship a new semver minor within the hour w/ this change & follow up on the PR!
This was referenced Mar 17, 2021
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
NOTE: This PR is a second take on #2147, based on feedback from @brianc
This PR adds an optional pool configuration maxUses and adds logic to the Pool that removes a connection upon release when it has been acquired and released maxUses number of times.
The intention is to help with balancing connections to a growing read replica cluster. Specifically, this scenario came up when adopting AWS Aurora in an environment where the read replica cluster expands and contracts based on weekly traffic cycles. When the pool is full of healthy connections to the pre-scale-up instances, the new instances never see any traffic unless you bounce all the app instances. By artificially "expending" a client after a number of uses, we can attain a better balance across all the replicas.
Also added some instructions in the main README listing the steps for dev setup
Thank you for considering these changes and your guidance along the way!