-
-
Notifications
You must be signed in to change notification settings - Fork 396
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
Improve robustness of rake work_jobs #411
Comments
Yeah Were the exceptions stopping your instance from updating the feeds? I agree that the robustness is not ideal, but I've not experience issues where my heroku instance stopped updating. |
Actually, it seems that Heroku counts a pair of worker + web as one "dyno": I run some other apps on the free tier with a worker + web combo and it works without major problems. |
In my case, the worker process stopped after 10-40 minutes, which also stopped updating feeds. The only way to restart it was to wait until the web dyno sleeps and then restarts itself and the worker. It looked something like:
Maybe it was just a bad day and Heroku was installing security patches or something... I also had an hourly timer, maybe it submitted jobs when the dynos were sent to sleep. Setting it to run every 10 minutes seems to have improved things a bit. |
It will replace Scheduler (for deployment on Heroku), so that no extra step is needed due to another spawn command being called on unicorn.rb starting clockwork. Still on Heroku, Procfile is updated, describing the worker and clock components (if the user wants a more robust architecture). This fixes stringer-rss#411 Also, for development environments, it will allow fetching feeds without having to manually running rake commands. The default interval for fetching feeds is 60s and it can be customized by env var FETCH_INTERVAL.
It will replace Scheduler (for deployment on Heroku), so that no extra step is needed due to another spawn command being called on unicorn.rb starting clockwork. Still on Heroku, Procfile is updated, describing the worker and clock components (if the user wants a more robust architecture). This fixes stringer-rss#411 Also, for development environments, it will allow fetching feeds without having to manually running rake commands. The default interval for fetching feeds is 10 min and it can be customized by env var FETCH_INTERVAL.
First of all, many thanks on creating this awesome RSS reader! Just what I was looking for and was about to create myself, but Stringer is so much better than anything I wanted :)
I installed it into Heroku and noticed a problem with reliability of the Heroku-specific
rake lazy_fetch
approach:While the
bundle exec rake work_jobs
is launched from config/unicorn.rb, it's never checked to be running and its delayed_job_pid is never used. It seems that Heroku kills long-running database connections either on purpose, or just randomly, which also causes an unhandled exception to kill thebundle exec rake work_jobs
process (example log). Whilerake lazy_fetch
continues to submit jobs, the worker process is dead and never restarted.It seems the best way would be to run
rake work_jobs
from a Procfile. I've tried two other workarounds and can confirm they work:The text was updated successfully, but these errors were encountered: