Skip to content
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

Merged
merged 4 commits into from
Sep 26, 2022

Conversation

gontarzpawel
Copy link
Contributor

@gontarzpawel gontarzpawel commented Sep 21, 2022

Description

Fix for the issue #230

  • update TTL to 500 ms upon finalisation
  • complete transactions instead of failing if fail reason is empty

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

Checklist

  • Linter passes correctly
  • Add tests which fail without the change (if possible)
  • All tests passing
  • Extended the README / documentation, if necessary

Does this introduce a breaking change?

  • Yes
  • No

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.

@render
Copy link

render bot commented Sep 21, 2022

@gontarzpawel gontarzpawel force-pushed the feat/ttl-update-transactions branch from 5abf9b0 to 35e0238 Compare September 21, 2022 07:47
@gontarzpawel gontarzpawel changed the title Update TTL of transactions upon finalisation Update TTL of transactions upon finalisation to 500 ms Sep 21, 2022
@@ -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
Copy link
Collaborator

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

Copy link
Contributor Author

@gontarzpawel gontarzpawel Sep 24, 2022

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

Copy link
Collaborator

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)
Copy link
Collaborator

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) {
Copy link
Collaborator

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.

@gontarzpawel gontarzpawel force-pushed the feat/ttl-update-transactions branch from b0547c9 to 930462c Compare September 26, 2022 16:47
@gontarzpawel gontarzpawel merged commit 893ece8 into master Sep 26, 2022
@gontarzpawel gontarzpawel deleted the feat/ttl-update-transactions branch September 26, 2022 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants