-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
refactor(concurrency): consistent node-level locks #13055
Conversation
5119f87
to
4442aa2
Compare
Several places in the gateway need a node-level lock, some of them used slightly different implementations. This refactor brings consistency in the ways we do node-level locking by using the same implementation (concurrency.with_worker_mutex) everywhere.
4442aa2
to
5755745
Compare
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.
Just one comment.
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 like the refactoring but I'm missing a little bit of context to fully understand what's going on here. I added one comment that might help me wrap my head around it.
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.
Now it all makes sense! Thank you for explanation 🙇 . I went through the logic here and in the libs you mentioned and everything looks good to me 👍
I just left one comment that's not really related to your refactor. I was just curious what 0.001
means. If you know - maybe you can extract it to a constant and give it a name?
Successfully created cherry-pick PR for |
Summary
Several places in the gateway need a node-level lock, some of them used slightly different implementations. This refactor brings consistency in the ways we do node-level locking by using the same implementation (concurrency.with_worker_mutex) everywhere.
Note: in order to maintain the logic of
declarative.import
unaltered, theconcurrency.with_worker_mutex
function has been slightly modified to return an additional valuettl
in case of timeout error, so thatretry_after
could be implemented as before.Checklist
changelog/unreleased/kong
orskip-changelog
label added on PR if changelog is unnecessary. README.mdIssue reference
KAG-2337