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

feat(actix): New Register [INGEST-1494] #1421

Merged
merged 19 commits into from
Aug 18, 2022

Conversation

tobias-wilfert
Copy link
Member

@tobias-wilfert tobias-wilfert commented Aug 17, 2022

General

With the generic Addr in place since #1405 this PR
makes a new Register for the Services, which replaces
the current hardcoded solution.

Design choices

  • The first approach was to use Arc<Option<Register>>
    however, this didn't work as Arc::new is not const fn.
    To avoid this lazy_static was used however that in
    turn didn't work as DerefMut was required and
    lazy_static only implements Deref.
  • A OnceBox is currently used for the Register which is
    initialised at the end of ServiceState::start() this
    avoids the need for any Options but also could cause
    issues in the future as the current registry is created
    at the beginning of the function and then gradually populated.
    A similar approach might need to be used in case of issues.

Future Steps

  • With the Register out of the way the next actor can be upgraded.
    A good choice for that is the Upstream Actor.

@flub
Copy link
Contributor

flub commented Aug 18, 2022

lgtm

@tobias-wilfert tobias-wilfert marked this pull request as ready for review August 18, 2022 08:21
@tobias-wilfert tobias-wilfert requested a review from a team August 18, 2022 08:21
@@ -36,7 +33,7 @@ impl Healthcheck {
///
/// Panics if the service was not started using [`Healthcheck::start`] prior to this being used.
pub fn from_registry() -> Addr<Self> {
ADDRESS.read().as_ref().unwrap().clone()
REGISTRY.get().unwrap().healthcheck.clone()
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if we could make this method generic on Service somehow. In C++ you could do std::get<T> to access a tuple by type, in Rust I would not know how to do it.

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah we wondered this as well but could not figure it out without dynamic dispatch (TypeId) but that would slow this down. I'm not sure how to do this at compile time, but it so feels like this should be possible.

Base automatically changed from tobias-wilfert/future-proofing-relay to master August 18, 2022 10:53
@tobias-wilfert tobias-wilfert mentioned this pull request Aug 18, 2022
30 tasks
@tobias-wilfert tobias-wilfert changed the title feat(actix): New Register feat(actix): New Register [INGEST-1494] Aug 18, 2022
@tobias-wilfert tobias-wilfert merged commit 3b538ae into master Aug 18, 2022
@tobias-wilfert tobias-wilfert deleted the tobias-wilfert/new-register branch August 18, 2022 14:29
Copy link
Member

@jan-auer jan-auer left a comment

Choose a reason for hiding this comment

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

Sorry for being late with this review. A few comments attached that can be addressed in a follow-up PR.


use relay_aws_extension::AwsExtension;
use relay_config::Config;
use relay_metrics::Aggregator;
use relay_redis::RedisPool;
use relay_system::Addr;
Copy link
Member

Choose a reason for hiding this comment

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

Please merge this input with the one below.

@@ -26,6 +28,8 @@ use crate::middlewares::{
};
use crate::{endpoints, utils};

pub static REGISTRY: OnceBox<Registry> = OnceBox::new();
Copy link
Member

@jan-auer jan-auer Aug 18, 2022

Choose a reason for hiding this comment

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

Please make this non-public and hide the implementation detail that this uses a OnceBox. Especially, this is considered infallible, and the unwrap should be hidden behind an accessor method:

impl Registry {
    fn get() -> &Self {
        // some comment on why we think this is safe (once it is safe)
        REGISTRY.get().unwrap()
    }
}

@@ -105,6 +109,11 @@ impl From<Context<ServerErrorKind>> for ServerError {
}
}

#[derive(Clone, Debug)]
pub struct Registry {
Copy link
Member

Choose a reason for hiding this comment

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

Please add documentation to this type.

@@ -36,7 +33,7 @@ impl Healthcheck {
///
/// Panics if the service was not started using [`Healthcheck::start`] prior to this being used.
pub fn from_registry() -> Addr<Self> {
Copy link
Member

@jan-auer jan-auer Aug 18, 2022

Choose a reason for hiding this comment

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

These static from_registry functions were a workaround to replace the trait method on actix::SystemService. Now that all our services are expected to be in the registry, we could move this to a mandatory Service::from_registry trait method which enforces that this is implemented for every service in the same way. Also, this means that we no longer have to copy-paste the doc comment.

Alternatively, we might not even need from_registry anymore. It's now as simple as:

Registry::get().healthcheck.send(_);

Copy link
Contributor

Choose a reason for hiding this comment

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

Having a ::from_registry() forces you to import the service type, this variation makes everyone import the Registry. The only argument I'm able to come up is that importing the service type makes it easier to discover in the code where the service is being used, so that would argue for keeping ::from_regsitry(). +1 to making it a trait method though.

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.

5 participants