-
Notifications
You must be signed in to change notification settings - Fork 93
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
ref(actix): Update Store Actor [INGEST-1565] #1415
Conversation
36d98ae
to
6ca4754
Compare
b9ab1f7
to
730621f
Compare
I think this might have been the wrong call, Instead I'd call the envelope something like It's perhaps a bit unfortunately that relay handles "envelopes" and the services also stuff messages into envelopes to send each other messages. But I can't think of any better naming for now. |
relay-server/src/actors/envelopes.rs
Outdated
.enable_all() | ||
.build() | ||
.unwrap(); | ||
let runtime = utils::construct_runtime(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC this now creates a runtime which can send messages to actix, but it doesn't really need that. I'd be fine with leaving this as calling the tokio builder directly, I don't mind a bit of being explicit as there's no tricky stuff going on like setting up the actix system that needs to be abstracted and documented. (I appreciate @jan-auer may have desired to hide the tokio builder, I'll politely disagree 😉 )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few reasons for keeping this abstraction:
- There will be plenty of runtimes constructed for all the services once they are migrated. This is a single line and makes it easier to read, writing a 5+ line block every time will just clutter our constructor functions.
- It gives us a single place to hook central concerns or enforce patterns. For example, in a follow-up I will require to set explicit names for every runtime, so this can simply become a required parameter of that function.
- Initializing the actix system for every runtime is actually desired here, since that removes any risk of accidentally forgetting it. Also, this means there can be a single TODO in the code base to remove it after the migration is done.
We will need to pass a flag or count to control whether this should be a single- or multi-threaded runtime, however.
Just a few small nits, but overall looks great. |
If we're renaming |
mod service; | ||
|
||
pub use self::controller::*; | ||
pub use self::service::*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would you say to make pub mod service
and remove the service::*
use? This is how you use it in #1421 (and the missing pub
is why that's currently unhappy) and it kind of makes sense (i'm generally not a fan of * imports)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was related to a comment by Jan:
In this case, I'd rather make this a private module and do a blanket export like for controller. This module will contain the most used types of this crate, so it's worth having them in the root namespace.
So I changed it here but forgot to change it in #1421 but that should be fixed now.
General
This PR updates the
Store
service to use the genericAddr
introducedin #1405, to avoid duplicate code, it moves the shared code out
to its own module in
relay-system
calledservice
.Some minor changes have been made to address the comments of Jan
on #1397.
Future Steps
Addr
in place the time has come to make a newregistry for the services, that replaces the hardcoded current solution.