carbonserver/quota: throughput racy counter fixes and refactoring #446
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.
This PR includes two fixes. Most of the observable fix is in the first commit. The second commit is more subtle and more about refactoring.
carbonserver: fix broken/untimely quota usage report/reset logics
The usageRefreshTimeout implementation in updateFileList is quite broken as it produces
report metric gaps from time to time.
And the listener.refreshQuotaAndUsage call after updateFileList in fileListUpdater loop
also causes incorrect quota usage report.
carbonserver/quota: fix racy throughput usage collection and throttling, with some refactorings
The original throughput usage collection and reset process are done though creating a new
throughput counter, which might be racy as report and reset are done in parallel. This commit
fixes it by resetting the same usage counter rather than creating new variables every time
during usage report.
At the same time, throughput reset are done in intervals (specified by carbonserver.quota-usage-report-frequency).
This means that there might be latency between resets and causing unnecessary throttling
when quota is saturated. This commit fixes it by checking against quota during the whole
range rather than just use fixed quota (similar to sliding window).
Include some tests for checking the changes above.
The rest of the changes are mainly refactoring, like renames and more comments.