-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
Run GoodJob on puma boot #91
Comments
Thank you for documenting this 🙏 I think you're right that configuring the adapter inside of I will dig into #89 too. I'm thinking that it may be safest to defer starting the background processing (e.g. the Notifier and Scheduler) until after the application has fully loaded via an initializer. |
Thanks! Yeah, I'm wondering if good_job needs a railtie. Perhaps it can use that to hook into the lifecycle of the rails server command, or something. |
Note that auto_terminate doesn't seem to have any effect in concurrent-ruby (ruby-concurrency/concurrent-ruby#841), so to get puma to reliably exit when running good_job async I had to change this to:
|
The startup/initialization issues have been addressed in #199 and #205 This using good_job/spec/test_app/config/environments/development.rb Lines 63 to 70 in b1cd222
|
Also, this is current Readme documentation for Puma: Lines 508 to 531 in b1cd222
|
I'm running an app on Heroku and want to use a single dyno, and good_job is fitting the bill nicely. I want to run good_job in async mode on puma boot. But I don't want to run a new good_job async if I start a rails console, so I can't put it in my
config/environments/production.rb
. I also noticed that just settingqueue_adapter
to:good_job
and then settingGOOD_JOB_EXECUTION_MODE=async
wasn't enough to reliably start good job on puma boot until an activejob was touched (and autoloading configured [and started] the queue adapter). So I ended up using:This means the autoloading behaviour is all good, in development it defaults to running inline but also has an async processor running in puma which is processing immediately, and always starts an async processor in the puma process in production while using external from rails console for enqueuing jobs.
This seemed like a useful little journey worth sharing. :-)
The text was updated successfully, but these errors were encountered: