-
Notifications
You must be signed in to change notification settings - Fork 264
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
Update TTL of transactions upon finalisation to 500 ms #235
Conversation
Your Render PR Server URL is https://chproxy-pr-235.onrender.com. Follow its progress at https://dashboard.render.com/static/srv-cclc1hta4990ukkqu4vg. |
5abf9b0
to
35e0238
Compare
@@ -21,6 +22,9 @@ type TransactionRegistry interface { | |||
Status(key *Key) (TransactionStatus, error) | |||
} | |||
|
|||
// transactionEndedTTL amount of time transaction record is kept after being updated | |||
const transactionEndedTTL = 500 * time.Millisecond |
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.
IMHO it should be configurable because some people will tell you they want 0 msec
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 was thinking about it too, but it makes few sense to expose it in the configuration because it's a technical detail of the implementation. I'd say instead of exposing it, we could expose a toggle feature flag to disable thundering herd explicitly
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.
here is my proposal: let's ship this feature first and let's see how people respond.
} | ||
|
||
// move ttls of mini redis to trigger the clean up transaction | ||
s.FastForward(updatedTTL) |
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.
nice trick, I was not aware of this function
@@ -79,3 +79,51 @@ func TestFailRedisTransaction(t *testing.T) { | |||
t.Fatalf("unexpected: transaction should curry fail reason") | |||
} | |||
} | |||
|
|||
func TestCleanupRedisTransaction(t *testing.T) { |
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.
IMHO, you should do 2 tests: one on failure (the one you did) and one on completion.
b0547c9
to
930462c
Compare
Description
Fix for the issue #230
500 ms
upon finalisationPull request type
Please check the type of change your PR introduces:
Checklist
Does this introduce a breaking change?
Further comments
I took a liberty also to do a small refactor in proxy.go. I moved logic away from
serveFromCache
that decides if query can be served from cache.