I am using collectiveidea for rails 2.3.8. I am creating array of delayed jobs to
perform some tasks, after some time I want to destroy all the delayed jobs which are running.
If anyone know the way to do this please help me.
You can invoke rake jobs:clear to delete all jobs in the queue.
In addition to the rake task, DelayedJob jobs are just a normal ActiveRecord model, so if you're in Ruby code you can do what you like with them:
Delayed::Job.destroy_all
Delayed::Job.delete_all
Delayed::Job.find(4).destroy
# etc.
Sounds like you've got a parent process that wants to timeout if its set of jobs doesn't complete within a certain time. Instead of hanging on to references to the jobs themselves, set a flag on a model that indicates that the process has given up. Jobs can check for that flag and short circuit if they're not needed anymore. (Your Job class should also wrap the contents of its #perform method in a timeout.)
It's almost always a bad idea to try to hang on to references to DJ objects as you seem to be suggesting.
Related
I'm using searchkick to work with elasticsearch on RoR 4 app. Searchkick is great, and surprisingly easy to use but some of it's options are not well described.
It's quite heavy traffic site so i'm trying to do most of the work asynchronously with sidekiq.
I;m trying to put updating index after creating/updating record to work asynchronously as well but :queue option seems even more fitting my case, as it's doing a bulk updates of missing records.
So, docs are saying to set_up redis, and callbacks option on model, and:
Then, set up a background job to run.
Searchkick::ProcessQueueJob.perform_later(class_name: "Product")
where to put that code?
When I add some records they are invisible until I run that once, so should it by run in a schedule? as CRON task?
Yes, you should set up the cron job: create rake task and start executing it. The searchkick callback as queue uses Redis queue. Once the job starts, it takes all accumulated "Product" ids so far and index them. So if you want to your Product's index bring up to date you need to perform that job repeatedly.
I'm planing in using a rake task to develop a long running background process for my rails application. Are rake tasks appropriate for this kind of processes? Ideally, I would like wrap it inside a linux daemon to be able to start and end the process easily.
If it's not the best option, which are the alternatives? I'm trying to avoid using a cron-based solution to avoid having to worry about the schedule and the posibility of having diferent running instances of the same process overlapping between them.
Thanks!
You can try delayed job with this extension.
class MyJob
include Delayed::ScheduledJob
run_every 1.day
def display_name
"MyJob"
end
def perform
# code to run ...
end
end
Or manually enqueue another job with Time.now + 5.minutes for example after current job is finished inside perform method.
Have you looked at the delayed_job gem?
https://github.com/collectiveidea/delayed_job
From their documentation:
Delayed::Job (or DJ) encapsulates the common pattern of asynchronously executing longer tasks in the background.
It is a direct extraction from Shopify where the job table is responsible for a multitude of core tasks. Amongst those tasks are:
sending massive newsletters
image resizing
http downloads
updating smart collections
updating solr, our search server, after product changes
batch imports
spam checks
it might depend on the kind of background jobs you need to run.
Basically if you need some sort of post processing on data the users enter, like rendering images for posts, do some async integration with third party resources, etc. then you better off with using Sidekiq (yeah, it's better than DelayedJob as people suggested)
But if you need to run something on schedule, like some say night downloads, cleaning up blocked users and stuff, then writing a rake task and kick it in with a cron task might be a perfectly useful option, coz you could use those tasks from CLI whenever you need to run them on demand
I am using https://github.com/ssoroka/scheduler_daemon for my scheduled jobs, but I would like jobs immediately with a command (rather than waiting for the delay specified in the task).
I've tried using rails runner TaskName.run but the class can never be found (runner.rb:53:in 'eval': uninitialized constant TaskName (NameError)).
How can I run the scheduled tasks immediately?
If I guess correctly, you want to call one of the scheduled task directly.
If I were you, I'd ask to the author directly, via the channel he points at in the readme: https://github.com/ssoroka/scheduler_daemon/issues
If there is a way to do it, I'm sure the author will be glad to explain it in the readme as well.
Corollary question: for a one-time schedule, do you want your direct trigger to cancel the schedule?
You don't need the scheduler to run the task for you, just call the MyTask.new.run directly.
I am using Resque to run a background process. This is how my background process works:
Scans through all the rows in an ActiveRecord model
Checks for a condition
Updates the row if the condition is met
And this needs to go on infinitely.
This is how I am trying to use Resque for my purpose, here's my worker class:
class ThumbnailMaker
#queue = :thumbnail_queue
def self.perform()
MyObj.check_thumbnails(root_url)
end
end
I understand the perform() method keeps a task in a queue, which is run periodically. In my case, I need a task that scans the whole table, so it runs for a longer time. Is it a good solution to my requirements?
On another note, I need the root url for my Rails application, which is easily obtained with the root_url in Rails Controller. But I need it in a class I have created, can you suggest me how I can get it here?
Resque is for queueing tasks to be run in the background; each item in the queue runs once and then is removed. What you want is more like a scheduled task--for example, a custom Rake task or other script that runs from time to time; there are many scheduling gems available for this kind of thing (wenever is very popular) or just use cron. There is a great RailsCasts episode about this very topic.
You might want to try putting your code in a rake task and running it periodically through a cron job. Resque/Redis seems a bit too much for your needs.
You may consider passing the root url in with as parameter if you are calling your class through your controller. Otherwise, you may want to set it as a ENV setting and configure each of your deployments accordingly.
I'm using Delayed Job to manage background work.
However I have some tasks that need to be executed at regular interval. Every hour, every day or every week for example.
For now, when I execute the task, I create a new one to be executed in one day/week/month.
However I don't really like it. If for any reason, the task isn't completely executed, we don't create the next one and we might lose the execution of the task.
How do you manage that kind of things (with delayed job) in your rails apps to be sure your regular tasks list remains correct ?
If you have access to Cron, I highly recommend Whenever
http://github.com/javan/whenever
You specify what you want to run and at what frequency in dead simple ruby, and whenever supplies rake tasks to convert this into a crontab and to update your system's crontab.
If you don't have access to frequent cron (like I don't, since we're on Heroku), then DJ is the way to go.
You have a couple options.
Do what you're doing. DJ will retry each task a certain number of times, so you have some leniency there
Put the code that creates the next DJ job in an ensure block, to make sure it gets created even after an exception or other bad event
Create another DJ that runs periodically, checks to make sure the appropriate DJs exist, and creates them if they don't. Of course, this is just as error prone as the other options, since the monitor and the actual DJ are both running in the same env, but it's something.
Is there any particular reason why you wouldn't use cron for this type of things?
Or maybe something more rubyish like rufus-scheduler, which is quite easy to use and very reliable.
If you don't need queuing, these tools are a way to go, I think.