Asynchronously refresh registry in transformation service#2060
Asynchronously refresh registry in transformation service#2060feast-ci-bot merged 1 commit intofeast-dev:masterfrom
Conversation
Signed-off-by: pyalex <moskalenko.alexey@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #2060 +/- ##
===========================================
+ Coverage 57.54% 83.14% +25.59%
===========================================
Files 100 100
Lines 8028 8099 +71
===========================================
+ Hits 4620 6734 +2114
+ Misses 3408 1365 -2043
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
| registry = Registry(registry_config, repo_path=self.repo_path) | ||
| registry.refresh() | ||
|
|
||
| self._registry = registry |
There was a problem hiding this comment.
What's the reasoning for this refactoring?
There was a problem hiding this comment.
if there're multiple threads accessing self._registry it makes sense to fully construct replacement (actual proto is being loaded in registry.refresh, so before that new Registry is still half baked) before making it available for everybody else
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: achals, pyalex The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/lgtm |
Signed-off-by: pyalex moskalenko.alexey@gmail.com
What this PR does / why we need it:
Currently cached registry could expire by preconfigured TTL and will be lazy reloaded on next request, which might affect performance of transformation service.
This PR proposes to run background thread that will periodically refresh registry instead.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?: