I have an application where I want to automatically deactivate a user 72 hours after they have been activated. I have set this up with Delayed Job, but am now wondering if that is the best option.
My question is, if I set a task for 72 hours in the future, will a worker be active for that entire 72 hours? (I'm concerned about this as Heroku charges by the hour)
I'm open to suggestion here as far as better ways of doing this goes. One idea I had was to set this up using an exp_date column and check against that at sign in there by eliminating the need for DJ completely.
My question is, if I set a task for 72 hours in the future, will a worker be active for that entire 72 hours? (I'm concerned about this as Heroku charges by the hour)
Yes, it will be up all time. Delayed job continuously pings the database to see if there any job in its queue.
And, regarding the best option i think i rather put one column knows as valid_upto and put the date till will be active. I only signins (or whatever) to only those user which has created_at dates less then or equal to valid_upto date. And, periodically may be once in month i will run one cron job to remove invalid users.
And, like #leesungchul suggested, you can use that, that looks cool.
You can use the workless gem which is an addon for delayed jobs so you don't leave your worker running constantly on heroku.
https://github.com/lostboy/workless
Related
I need to implement user faced scheduler, like users have reports and might choose schedule when they want those reports being sent to them.
Requirements are quote complex, like there should be schedules like each 12 hours, each 30 minutes, each second day, at Fridays at 1am, last Sunday of the months etc.
Is there Rails solution for that our should I create it from the ground?
Thanks!
Most schedulers for rails and ruby depend on a static file. You can use a queuing system like Delayed Job and make every job enqueue itself for next time after success. Or you can do a basic SheduledJob model which relates to the user, and stores the periodicity, next execution and last execution. And use a normal (frequent) scheduled task engine like clockwork to check for pending jobs.
I'd like to make an email notification if SomeModel has not been updated for 2 hours.
What is the best way to implement it?
After a model has been saved, queue up a background job to run 2 hours from that time to send the email. When a new job is enqueued, remove any still-unrun jobs that are still on the queue.
resque-scheduler providers a pretty simple way of doing this, assuming you have redis up and running.
Personally I find the solution that #x1a4 proposes to be somewhat overkill. Given the relatively large window of 2 hours, I would just run a job periodically (say, once every 10-15 minutes), then search all Models for updated_at <= 2.hours.ago and send out the emails.
As for scheduling that job to run every 15 minutes, there are several options. You may use resque-scheduler, if you are using Resque. You may also use the standard system cron, but will incur some fairly substantial overhead starting Rails each time the job runs. I also have written a distributed scheduler gem (i.e. cron that can run on multiple machines, but act like it's only running on one), which uses Redis under the hood.
I'm trying to create a job in order to send a notification to a Twilio call, therefore it is important to have a robust solution that can make sure jobs are run at a specific time (I don't think being put into a queue is accurate enough).
What is the best solution for this type of a task?
These notifications need to happen at a specific time in the call. Such as "1 minute left". Therefore it needs to be able to:
Run at arbitrary times (1:22PM or 2:45AM)
Be defined by user input (they set the time of the call)
(It would be nice if that solution could run on Heroku)
You can use Heroku cron to run jobs either daily or hourly.
Daily cron is free, hourly cron costs $3/month: http://addons.heroku.com/cron.
Typically cron runs when you first initiate it (i.e. if you set it up at 3pm, it'll run at 3pm every day), but you can change that by sending an e-mail to support#heroku.com.
To run code in a cron, add your code to a cron.rake file and check out the cron docs here.
FYI
Heroku's own samples for cron suggest doing a time check, i.e.
if Time.now.hour % 4 == 0 # run every four hours
...
But, if you are running a daily cron, the code will run at a time that is likely to fail the above conditional. So, unless you are paying for hourly cron and you only want it to run specific hours, leave out that part of their sample code and just include your own code normally.
Running at Specific Times
Try delayed_job's :run_at column, which may give you the flexibility you need to run jobs at very specific times.
Heroku Docs: http://devcenter.heroku.com/articles/delayed-job
You need to add a cronjob for that. If you are on a Linux box then you can add a cron to the crontab and specify the time at which it runs. It is very flexible. You can find the details here:
http://en.wikipedia.org/wiki/Cron
If you want to do it in a ruby way, try whenever gem:
https://github.com/javan/whenever
For the specific case that you have mentioned, I think that you should give delayed_job a try:
https://github.com/collectiveidea/delayed_job#readme
it has a run_at option where you can specify the time at which you want to run the job.
Goto cron jobs in your hosting control panel
If I need to create recurring tasks in delayed jobs, what is a clean solution? I have an import task that I want to run every 5 minutes, but I don't want to fire up rails/rake in order to tell it to create a Delayed job that can be picked up. If Rails is already running on a system, perhaps I can just create an HTTP request that will make the rails app fire off a DJ? I could put that cron task in a ruby script which runs every 5 minutes, making requests to a server, but without firing up rails. What do you think?
This fork of delayed_job has recurrence built right in (and there may be other forks that do the same):
http://github.com/andrewroth/delayed_job
The cron approach still seems to be quite clean. It need only involve running a rake invocation, not a full Rails server. Rake doesn't need Rails to be running to work.
However if you really don't like that approach then you could arrange for the recurring jobs to be re-queue themselves when they are being processed setting a run_at time to 5 minutes (or whatever) in the future. Obviously you'd need to prime the queue the first time and make sure the delayed_job server stays running
About that... I have the same desire,
I'm planning to have a cron to fire up a curl request at a specific route at my site every 5 minutes, so it runs a action with the result, and I'm gonna be pretty sure it only ran once.
My purposes includes: Awarding Badges and compiling some Averages
I have a ruby on rails app that uses Heroku. I have the need to run things like import/export tasks on our db that lock up the whole system since they are so heavy on the DB. Is there a way to tell the system to only run these tasks when the database is not being used at that second?
There is no built-in way to schedule a job like this. There are a few things you can do, though.
Schedule the jobs to run during the least busy hours of the day. That will depend on your business, customer base and so on, but hopefully there is a window that is more suitable than others.
You could write your batch job to run for a longer time, doing small units of work. Between each unit of work, sleep for a few seconds, or take a look at the current load average and decide what to do based on that. This should lower the impact of the batch jobs.
Have the website update a "lock" somewhere, either in the database or in a memcached or something. If your normal website usage updates the database, you could look at the existing updated_at. Then only do batch work when there hasn't been any activity for a while. This doesn't guarantee that a new user won't pop in at the same time your batch job runs, of course, but could be a way to find a window where the site is less used.
Have you looked into using Background Jobs / Workers on Heroku? It's also worth reading about Heroku's Delayed Job queuing system