fix(plugin): RL instances sync to the same DB at same rate #12003
Conversation
This file contains 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
StarlightIbuki
force-pushed
the
fix/rl-sync-share-timer
branch
4 times, most recently
from
f1d96eb to
0c8bcd9
Compare
StarlightIbuki
force-pushed
the
fix/rl-sync-share-timer
branch
from
16a42c2 to
d46f872
Compare
ADD-SP
approved these changes
Nov 14, 2023
1 task
samugi
reviewed
Nov 14, 2023
StarlightIbuki
commented
Nov 14, 2023
2 tasks
samugi
reviewed
Nov 15, 2023
StarlightIbuki
force-pushed
the
fix/rl-sync-share-timer
branch
from
02f8c65 to
b561e45
Compare
and same rate All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced. Fix KAG-2904 Co-authored-by: samugi <[email protected]>
StarlightIbuki
force-pushed
the
fix/rl-sync-share-timer
branch
from
b561e45 to
6d42dbf
Compare
samugi
approved these changes
Nov 16, 2023
hanshuebner
pushed a commit
that referenced
this pull request
Nov 20, 2023
All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced. The timer will sync not just the same instance's counters but all counters in the same DB. This is a compromise given the emergency and we prefer simplicity over correctness for this behavior. Full changelog - The counter table is split with DB; - Timers are created when a request hits; - The sync_rate is guaranteed with limited running timers and timer delay - Cover the case in the integration test by "with_sync_rate" Fix KAG-2904 Co-authored-by: samugi <[email protected]>
windmgc
pushed a commit
that referenced
this pull request
Jan 24, 2024
All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced. The timer will sync not just the same instance's counters but all counters in the same DB. This is a compromise given the emergency and we prefer simplicity over correctness for this behavior. Full changelog - The counter table is split with DB; - Timers are created when a request hits; - The sync_rate is guaranteed with limited running timers and timer delay - Cover the case in the integration test by "with_sync_rate" Fix KAG-2904 Co-authored-by: samugi <[email protected]>
3 tasks
windmgc
pushed a commit
that referenced
this pull request
Mar 7, 2024
All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced. The timer will sync not just the same instance's counters but all counters in the same DB. This is a compromise given the emergency and we prefer simplicity over correctness for this behavior. Full changelog - The counter table is split with DB; - Timers are created when a request hits; - The sync_rate is guaranteed with limited running timers and timer delay - Cover the case in the integration test by "with_sync_rate" Fix KAG-2904 Co-authored-by: samugi <[email protected]>
windmgc
pushed a commit
that referenced
this pull request
Mar 8, 2024
All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced. The timer will sync not just the same instance's counters but all counters in the same DB. This is a compromise given the emergency and we prefer simplicity over correctness for this behavior. Full changelog - The counter table is split with DB; - Timers are created when a request hits; - The sync_rate is guaranteed with limited running timers and timer delay - Cover the case in the integration test by "with_sync_rate" Fix KAG-2904 Co-authored-by: samugi <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
All rate-limiting plugin instance syncs with the same plugin config, that is the very first config got hit by a request, and they all sync with the same rate. Even a config update won't change the DB to be synced.
The timer will sync not just the same instance's counters but all counters in the same DB. This is a compromise given the emergency and we prefer simplicity over correctness for this behavior.
Checklist
changelog/unreleased/kongorskip-changeloglabel added on PR if changelog is unnecessary. README.mdFull changelog
with_sync_rate"Issue reference
Fix KAG-2904