Application lifecycle callbacks #2134
casperisfine
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Context
There are a bunch of features I'd like to add to Rails that necessitate to have some kind of before or after fork callback.
To give just one example, I'd like to have Rails pre-warm the connection pool to avoid the common problem of the first request being slower because it needs to connect to the database.
This can't just be done at the end of boot, because it's very likely the server will later fork. I can use a decorator around
Process._fork
, but this is a fairly low value signal, as it may not be the server forking to serve requests, but some code doingfork + exec
(weird but possible).Existing APIs
Right now each server define its own callbacks and users have to bridge the gap.
e.g. Unicorn will give you
after_fork do |server, worker|
inunicorn.rb
, Puma will give youafter_worker_fork do
inpuma.rb
etc.Idea
I'd like if server would simply check for
respond_to?
on the application, e.g.:The issue with that is most servers use
Rack::Builder#to_app
which returns a middleware stack, so the only exposed method really iscall
.It would be nice if there was a way for the server to get the
run
argument, which in the case of Rails isRails.application
, to be able to check for common callbacks there.Beta Was this translation helpful? Give feedback.
All reactions