Every repository with this icon (
Every repository with this icon (
| Description: | Database backed asynchronous priority queue -- Extracted from Shopify edit |
-
I had to paste the rake tasks jobs:work and jobs:clear into my local rakefile.
Comments
-
Would be great to see an example of how to override the worker's name.
Comments
martennilsson
Tue Aug 18 00:22:41 -0700 2009
| link
hear, hear
-
Under normal conditions delayed jobs run and report results as expected:
*** Starting job worker host:Erics-MacBook.local pid:19112 About to perform job 1 jobs processed at 6.1079 j/s, 0 failed ...However, when a job fails, it attempts to perform it a second time and displays the result as 2 errors:
*** Starting job worker host:Erics-MacBook.local pid:19103 About to perform job About to perform job 2 jobs processed at 22.1354 j/s, 2 failed ... About to perform job About to perform job 2 jobs processed at 89.2026 j/s, 2 failed ... 2 jobs processed at 47.0045 j/s, 2 failed ... About to perform job About to perform job 2 jobs processed at 90.6083 j/s, 2 failed ...Here is the code that performs the delayed job:
class TestJob def initialize puts "Job created" end def perform puts "About to perform job" raise "Ooops" end endComments
-
When MAX_ATTEMPTS is set to 0 and an error occurs the last_error field is not set.
Comments
-
DJ expects the delayed Model to inherit from AR? (resolved -> my fault)
1 comment Created 3 months ago by fwoeck[sorry, this was my fault]
Hi,
the model, my jobs get their info from is stored in a couchdb instance.
The background process produces these kind of errors:
MailJob failed with ActiveRecord::RecordNotFound: Couldn't find MailReceiver with ID=b8a6908bd4fdbf4b86236f1e44ff1056 - 1 failed attempts
But sometimes the queuedelivery works with the second or third try!
I could imagine that DJ expects the MailJob model to come from AR?Any hints are very welcome ;)
-- FrankComments
-
Disable handle_asynchronously in test mode
2 comments Created 3 months ago by jonleightonIf you're using handle_asynchronously, I think it's reasonable to assume that you want the delaying behaviour to be "transparent" within your app. Therefore, in test mode, the relevant methods should not actually become a delayed job.
I'm achieving this currently using:
# Disable transparent delayed_job methods in test mode module Delayed::MessageSending def send_later(method, *args) send(method, *args) end endThis has the side effect of also disabling send_later. I have mixed feelings about whether that should actually happen, as it's a more explicit call, so would be interested in thoughts on that.
Comments
What about only calling #handle_asynchronously if you're in test mode?
def do_something # here end handle_asynchronously :do_something unless Rails.env.test?Or less intrusive…make all of your #handle_asynchronously calls in config/environments/production.rb?
jonleighton
Mon Aug 24 09:42:48 -0700 2009
| link
Hmm. The first solution isn't great because rcov will report that line as un-tested. The second - I'd prefer not as this is something which will easily confuse somebody who hasn't seen the codebase before.
-
README.textile not displaying code examples properly
1 comment Created 3 months ago by technicalpicklesIn textile, you need to use pre and code tags around large code chunks.
I've made changes to my to display more nicely: http://github.com/technicalpickles/delayed_job/tree/readme_code
Comments
trevorturk
Mon Aug 31 13:08:04 -0700 2009
| link
I also made a new readme that includes more examples (e.g. send_later):
-
It seems that a user of delayed_job is always going to need to make a migration for the delayed_jobs table. It would make sense to provide a generator to automate this process.
I've made a small one in my fork: http://github.com/technicalpickles/delayed_job/tree/generator
Comments
Not sure if/when this was merged in, but you can now say script/generate delayed and this happens automagically.
technicalpickles
Fri Nov 20 17:33:53 -0800 2009
| link
Are you sure? I'm looking at the upstream repo, and not seeing any code related to a generator.
I'll take a closer look tomorrow, the reason I say so is this morning I was in my repo and tried script/generate delayed and it worked and generated a migration for me. I'll try and track down where it came from.
In looking through my system I have the delayed_job gem installed (which is ironic since I was asking tobi earlier if he was going to push one). From other discussions I was informed that gem is actually based on the collectiveidea fork. Looking at that code there is a generator there. So, my guess is though I'm using tobi's fork/gem, script/generate picked up on the other gem's generator.
Summary being, I stand corrected (2nd time today), but the collectiveidea fork has it if you're interested.
-
As you can see, the daemon uses the wrong db credentials unless RAILS_ENV is passed in:
[root@my_server ~]# /home/deploy/my_app/script/delayed_job -e staging start /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:547:in `real_connect': Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2) (Mysql::Error) from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:547:in `connect' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:199:in `initialize' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:74:in `new' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:74:in `mysql_connection' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `send' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:223:in `new_connection' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:245:in `checkout_new_connection' from /home/deploy/rails_apps/my_app/releases/20090916055509/vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb:188:in `checkout' ... 19 levels... from /home/deploy/my_app/config/../vendor/rails/railties/lib/initializer.rb:112:in `run' from /home/deploy/my_app/config/environment.rb:6 from /home/deploy/my_app/script/delayed_job:3:in `require' from /home/deploy/my_app/script/delayed_job:3 [root@my_server ~]# RAILS_ENV=staging /home/deploy/my_app/script/delayed_job -e staging start [root@my_server ~]#Comments
Well you can't automatically deduce the rails_env.
You can launch the same application files in dev and prod.
So I guess passing it in argument is the best way. -
delayed_job dies with database connection issues
0 comments Created 2 months ago by jconleyReceived this in our delayed_job.log... and then the DJ process dies. My best guess so far is there was a momentary network disruption between firewalls of our app and db networks.
<ActiveRecord::StatementInvalid: Mysql::Error: MySQL server has gone away: UPDATE
delayed_jobsSET locked_by = null, locked_at = null WHERE (locked_by = 'delayed_job host:myhost pid:12345') >Would be nice if DJ had more robust connection handling... i.e. catch this issue, and retry the connection until it is successful... otherwise we have to write a script to restart DJ periodically, or detect when jobs in the queue are stale.
Comments
-
Exception in db_time_now from Time.zone.now when default_timezone is :local (ie no zone)
3 comments Created about 1 month ago by gregclarDelayed::Job
def self.db_time_now (ActiveRecord::Base.default_timezone == :utc) ? Time.now.utc : Time.zone.now endApp is in rails 2.2.3 on ruby 1.8.7.
[apphome]/config/environments does not set config.time_zone.
error demo'd in console:
> ruby script/console Loading development environment (Rails 2.2.3) >> ActiveRecord::Base.default_timezone => :local >> Time.zone.now NoMethodError: You have a nil object when you didn't expect it! The error occurred while evaluating nil.now from (irb):2Simple work-around: use Time.now instead of Time.zone.now, which works for my Rails settings, but not sure that is a general solution.
Comments
kossnocorp
Sun Oct 25 19:48:08 -0700 2009
| link
-
Truncated YAML crashes the delayed_job daemon
0 comments Created about 1 month ago by dballWe were working with some beefy jobs that silently overflowed the default TEXT columns in mysql. The truncated YAML data were unable to be loaded, and were causing the daemon to crash. It looks like incomplete error handling in the job.deserialize method to me; the second YAML.load call doesn't have a rescue block, and the main rescue block for the method doesn't catch the YAML syntax error.
Comments
-
Periodically, I will have jobs that should be running, but... aren't. I mean they have values in the "locked_at" and "locked_by" columns, and they are clogging up the queue, but they never finish executing.
Comments
-
delayed_job start creates a new process even if one is already running
0 comments Created 22 days ago by wr0ngwayRun "script/delayed_job start" twice, two processes will get started. The oldest one has to be killed manually since the pid file gets overwritten. The start action should check and not start a new process if one is already running (pid file exists, and a process with that pid is also running).
Comments
-
Perhaps the Delayed::Job queue is order agnostic, but I would expect it to process jobs of the same priority in the same order as they were added to the queue.
Here's a failing test that I wrote against one of my models:
def test_delayed_job
comment = Comment.create!(:body => 'This is a comment') assert_equal 0, Delayed::Job.find(:all).size comment.send_later(:update_attribute, :body, 'Comment the first') comment.send_later(:update_attribute, :body, 'Comment the second') assert_equal [2, 0], Delayed::Job.work_off assert_equal 'Comment the second', comment.reload.bodyend
Unfortunately, that test fails with the following output:
<"Comment the second"> expected but was <"Comment the first">.
The order in which the two updates are dequeued differs from the order in which the two updates were enqueued. Is this the expected behavior?
Comments
I'm guessing this probably relates to this commit:
http://github.com/tobi/delayed_job/commit/d0a9c2d5044746445ec7beebf3f0ca62ea12c525
-
Since github doesn't support compiling gems anymore, do you have any plans to move delayed_job onto gemcutter? I'm trying to get rid of my references to github as a source, but delayed_job is one of the few stragglers left.
I can push jerryvos-delayed_job to gemcutter for my own purposes, but would prefer to just use a real delayed_job gem or a tobi- one.
I'd happily provide any assistance in doing this and/or push a gem there myself, but don't want to steal ownership of delayed_job out there (though if you ask me to push it I can and then add you as an admin of it).
Comments
The gem is already available on gemcutter, but it's collectiveidea's fork.












You need to require the rake tasks in your app. This is actually working as designed by rails.
Add the following to your Rakefile:
require 'delayed/tasks'