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

[Bifrost] Eager providers initialization #1681

Merged
merged 1 commit into from
Jul 3, 2024
Merged

[Bifrost] Eager providers initialization #1681

merged 1 commit into from
Jul 3, 2024

Conversation

AhmedSoliman
Copy link
Contributor

@AhmedSoliman AhmedSoliman commented Jul 2, 2024

[Bifrost] Eager providers initialization

Bifrost providers are now initialized in two stages. An initialization that happens on startup to ensure all critical initialization and validation happens before server startup.
After initialization, loglets will get a notification from watchdog to perform any background lazy initialization work if necessary.

Benefits:

  • Removes the need to always "check if initialized" internally, or the use of "OnceLock" and other techniques to check if it's initialized or not.
  • Allows a potential validation step before server startup. Potentially fetching the metadata and validating all LogletParams for each provider in metadata against providers to reduce the chance of validation errors at construction time.
  • Allows construction of providers to be async without impacting providers' map access performance

This PR also allows bifrost to be supplied a set of "Factories" to externalize how a loglet is constructed. This is crucial for the replicated-loglet since it depends on networking and other components that bifrost interface doesn't need to know about. A side benefit of this is that we can be very precise on which providers are enabled for a given Bifrost instance. For example, InMemory loglet is now not allowed by default in restate-server binary (debateable if we should put it back or not)


Stack created with Sapling. Best reviewed with ReviewStack.

Bifrost providers are now initialized in two stages. An initialization that happens on startup to ensure all critical initialization and validation happens before server startup.
After initialization, loglets will get a notification from watchdog to perform any background lazy initialization work if necessary.

Benefits:
- Removes the need to always "check if initialized" internally, or the use of "OnceLock" and other techniques to check if it's initialized or not.
- Allows a potential validation step before server startup. Potentially fetching the metadata and validating all `LogletParams` for each provider in metadata against providers to reduce the chance of validation errors at construction time.
- Allows construction of providers to be async without impacting providers' map access performance

This PR also allows bifrost to be supplied a set of "Factories" to externalize how a loglet is constructed. This is crucial for the replicated-loglet since it depends on networking and other components that bifrost interface doesn't need to know about. A side benefit of this is that we can be very precise on which providers are _enabled_ for a given Bifrost instance. For example, InMemory loglet is now not allowed by default in restate-server binary (debateable if we should put it back or not)
@AhmedSoliman AhmedSoliman marked this pull request as ready for review July 2, 2024 12:45
@AhmedSoliman AhmedSoliman requested a review from tillrohrmann July 2, 2024 12:47
Copy link

github-actions bot commented Jul 2, 2024

Test Results

102 files  ±0  102 suites  ±0   20m 41s ⏱️ -3s
 84 tests ±0   84 ✅ ±0  0 💤 ±0  0 ❌ ±0 
215 runs  ±0  215 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 27dd0aa. ± Comparison against base commit 8b08fe5.

Copy link
Contributor

@tillrohrmann tillrohrmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The eager providers initialization looks good to me. +1 for merging :-)

@AhmedSoliman AhmedSoliman merged commit 27dd0aa into main Jul 3, 2024
7 checks passed
@AhmedSoliman AhmedSoliman deleted the pr1681 branch July 3, 2024 08:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants