tx limiter: fix quota leak if Begin() errors or if the tx killer runs#6731
Merged
systay merged 1 commit intovitessio:masterfrom Oct 7, 2020
Merged
tx limiter: fix quota leak if Begin() errors or if the tx killer runs#6731systay merged 1 commit intovitessio:masterfrom
systay merged 1 commit intovitessio:masterfrom
Conversation
Collaborator
Author
|
I'll look into the unit test race failure |
The transaction limiter reduces a caller ID's quota within the transaction pool to some fraction of the overall pool size. We've found it useful for tightening the blast radius when a single client starts to have long transactions for whatever reason. We noticed in a development enviornment that the tx limiter was preventing any new transactions for a particular caller ID even though no transactions for that user were already in progress. I'm not too familiar with this code, although it seems a bit brittle. In this PR I've tried to make sure that if there's an error grabbing a connection from the connection pool or if a connection is killed by the transaction killer, tx limiter quota is restored. I'd love for anyone who is to take a close look at this. It seems possible that killed transactions were also previously not logged, and this might fix that too?... See vitessio#6727 Signed-off-by: David Weitzman <dweitzman@pinterest.com>
dweitzman
force-pushed
the
fix_tx_limiter
branch
from
39151c1 to
264ae74
Compare
Collaborator
Author
|
Fixed the race. The fake transaction limiter needed to use a mutex when saving/reading logs of the requests made to it. |
systay
approved these changes
Oct 7, 2020
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
4 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.
The transaction limiter reduces a caller ID's quota within the transaction
pool to some fraction of the overall pool size. We've found it useful for
tightening the blast radius when a single client starts to have long
transactions for whatever reason.
We noticed in a development enviornment that the tx limiter was preventing
any new transactions for a particular caller ID even though no transactions
for that user were already in progress.
I'm not too familiar with this code, although it seems a bit brittle. In this PR
I've tried to make sure that if there's an error grabbing a connection from the
connection pool or if a connection is killed by the transaction killer, tx limiter
quota is restored.
I'd love for anyone who is to take a close look at this.
It seems possible that killed transactions were also previously not logged, and
this might fix that too?...
See #6727
Signed-off-by: David Weitzman dweitzman@pinterest.com