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

[💡 FEATURE REQUEST]: after_init phase command #1554

Closed
rauanmayemir opened this issue May 8, 2023 · 6 comments · Fixed by roadrunner-server/server#44 or roadrunner-server/sdk#73
Assignees
Labels
C-feature-request Category: feature requested, but need to be discussed
Milestone

Comments

@rauanmayemir
Copy link

Plugin

Server

I have an idea!

It would be nice to have an after_init section similar to server.on_init that would run after the server is initialized and ready to receive requests.

Extra nice option: allowing to have the same section for each plugin (unless it's meaningless because server.after_init would run after all the plugins are done loading). E.g: I can have this command for http or grpc, so that I could start accepting requests without waiting for jobs plugin.

@rauanmayemir rauanmayemir added the C-feature-request Category: feature requested, but need to be discussed label May 8, 2023
@rustatian rustatian modified the milestones: 2023.1.3, v2023.3.0 May 8, 2023
@rustatian rustatian modified the milestones: v2023.3.0, v2023.2.0 May 22, 2023
@rustatian
Copy link
Member

Done, in testing now, will be in the v2023.2.0

@rauanmayemir
Copy link
Author

The implementation is a bit quirky as after_init is being called by the server and then called again by each roadrunner plugin.

The initial proposal was supposed to be like this:

  1. Allow each plugin to have an after_init phase
  2. Add a global after_init that would be called after all the plugins are ready

It is a single-use command that only fires once. Anything else could be done by polling healthz.

I was trying to adopt this feature like this: process manager pre-opens a notification file descriptor and then expects the RR process to write to that FD and then close it. I verified that it works, but only once. I then get two more log lines: signal: broken pipe.

The goal is being able to mark container ready without resorting to polling.

@rustatian
Copy link
Member

@rauanmayemir
after_init triggered once per pool initialization (e.g., per-plugin), there are no additional calls. Each plugin does have an after_init configuration to override the server's after_init general command. It can be specified per-pool. This option is not documented, because after_init is a questionable option which has very tiny scope where to use it. It won't be updated until I get additional feedback from the community about use-cases for this feature.

@rauanmayemir
Copy link
Author

If I wanted a notification from a plugin, I guess I would have set e.g jobs.after_init and this actually makes sense e.g for dynamically creating and launching job pipelines.

This results in a confusion. You specify server.after_init, but for some reason it's called by all the plugins. So ultimately, it's not server's after_init, it's just a section to specify the default command.

I was the one requesting the feature, but I don't know how I can use this or what for. 😄

@rustatian
Copy link
Member

Thus, I would suggest you to describe your request in a new FR.
Describe use cases, proposed configuration options, etc.

@rauanmayemir
Copy link
Author

To re-quote the original request:

It would be nice to have an after_init section similar to server.on_init that would run after the server is initialized and ready to receive requests.

It's basically a readiness notification that would allow process manager not to poll /health for readiness, because RR process won't be ready until it sends back the notification. Essentially, something like previously mentioned sdnotify, but for non-systemd use case.

I was confused thinking 'server' encompasses everything, not just a plugin called 'server'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: feature requested, but need to be discussed
Projects
Status: ✅ Done
Status: Done
2 participants