I'm having trouble using collectiveidea/delayed_jobs to process tasks in Rails 4. Namely, it works, but doesn't seem to want to update code based on recent file updates. This is true on both production and development environments, although I'm focusing on debugging in development first, just to see what might be happening.
I'm on versions delayed_job (4.1.1) and delayed_job_active_record (4.1.0).
If I run a job synchronously (skipping the delayed_jobs worker) things process fine (the following code is what I use to test that):
app/config/initializers/delayed_job.rb
Delayed::Worker.delay_jobs = !(Rails.env.test? || Rails.env.development?)
But with the delayed_jobs table queue / worker running I end up with a significantly older version of my job per outdated code.
I've tried locking the daemons gem at 1.1.9, as mentioned here without luck.
Gemfile
gem 'delayed_job_active_record'
gem 'daemons', '1.1.9'
I could share more code, but I'm not sure it'd do much good. My testing shows just what I've mentioned.
Trouble restarting delayed_job workers is a known issue elsewhere. But my issue seems to be more specifically that, even if I can restart workers, some sort of more general cache seems to be interfering with proper execution. I have also tried restarting application servers in both dev and prod with no luck.
Any similar stories or tips would be greatly helpful!
Related
I am developing a gem for my application and want to see if my gem is working on a real application or not, but the problem is if I want to see the changes in the application I have to restart the server.
I have googled the issue but all the solutions were either not working or relatively old (backing to rails 3 or so); is there any way to see the changes without restarting the server in rails 5?
I don't think you can because Gems are initialized when you start the server. Any change to the gemfile or gems themselves will require a server restart. The same is true about Routes, Config, etc.
I have an instance of Locomotive CMS running on Heroku and it has been running fine for about a year. I am the only developer so there have been no deployments since the last working deployment.
Yesterday I made an update to the config/environments/production.rb - all that I changed were the values for the existing ActionMailer settings. Committed and pushed, et voila - the app no longer functions.
The app works on the dev machine, when run in production and dev mode.
I'm a newb when it comes to Rails and Heroku, so I'm having some difficulty interpreting the log.
I've posted the log at: http://pastebin.com/GZpRaue6
The only clear error that I can see in the log is:
Couldn't load redcloth_scan
I have tried adding gem 'RedCloth' to my gems file and bundle installed, as it wasn't explicitly required in the original version of the source, but this has made no difference.
There is no mention of redcloth_scan in my gemfile.lock, but RedCloth is listed as a dependency of Locomotive.
locomotive_cms (2.0.0.rc9)
RedCloth (~> 4.2.8)
After much messing about with the gemfile, each gemfile alteration simply causing different problems with loading the binaries for a different gem. So not an issue specific to redcloth.
I came across this SO post: What is the purpose of vendor/bundle? Heroku tells me to remove it
This use of --path is certainly not an elegant solution, my app never needed this before - something must have changed in Heroku and I'm hoping to be able to move away from this in future. But it's fixed it for now and that's good enough for me.
I am using Rails 3.0.1, Bundler 1.0.3 and Ruby 1.9.2p0 (2010-08-18 revision 29036). Everything was fine and fast until I started adding Devise & Omniauth. From that on everything involving initializing Bundler (calling Bundler.require as in application.rb) took ages (by means of 30-50 seconds which is a lot for e.g. calling 'rake routes').
The time is lost in 'config/application.rb':
Bundler.require(:default, Rails.env) if defined?(Bundler)
I tried to disable / enable gems (like the ones I added last or all test-related gems) but it seems as if it is an issue involving a barrier of the amount of total gems rather than any specific coding problems in certain gems.
For final testing I created a fresh Rails 3.0.1 Project with a new RVM gemset and added the gems one by one. Still the same at around 30-50 gems (which is not unusual for large projects and has never before been an issue).
Any ideas (besides: decreasing your gem count)?
Same problem. Adding gems appropriate increase bootup environment time by bundler. I havn't resolved this issue yet. It is about 20 seconds overhead before specs will run.
It makes me crazy ;..(
The best I've come up is to utilize spork. It works great and makes up for the slow startup. Spork starts up a DRB Server to which rspec / cucumber can connect and use preloaded ruby processes to run the tests. It reloads certain files (Tests, Classes, ...) for each run, so it is almost as fresh as a new process.
https://github.com/timcharper/spork
I have an app that works perfectly on my local machine and am deploying it now. I have the VPS all set up and it pretty much works, as well. My problem comes from not being able to start delayed_job. I do the "ruby script/delayed_job start RAILS_ENV=production" while SSHd to the app and it returns "delayed_job: process with pid 11547 started." When I look for the process in htop, I can't find it.
So I dug around and read that Monit can keep delayed_job going. I set that up, hoping I could start up the delayed_job that way. There's no delayed_job.pid, though, so I didn't get far. I ended up setting up nginx and mysql in it, though, and would like to finish setting up delayed_job. The lack of delayed_job.pid gets in the way.
When I SSH into the app and run "rake jobs:work RAILS_ENV=production", everything works just fine. So I'm pretty sure the app itself is fine.
I'm using collectiveidea's delayed_job. Thanks for any help.
It turns out that there's a problem with the daemons gem. Using the ghazel-daemons fork works perfectly. Now onto setting up Monit.
In my case, I just declare that it must use version 1.0.10 of daemons in the Gemfile:
gem "daemons", "= 1.0.10"
Which is the previous version of daemons from 2008.
Having the same problems as this post, except I don't think the solution is the same unfortunately.
I'm getting this error message:
Rails requires RubyGems >= 0.9.4. Please install RubyGems
when I run a script/runner job in Cron, but it works perfectly fine when I run it in a terminal on the same server.
The rails server also runs fine. I only have trouble running script/runner's in cron. It seems to want to have a terminal attached...
Try which ruby and which gem from your cron job and also from the terminal. Are you accessing different binaries? You didn't mention which OS and which shell, but you may have a different $PATH when running headless.
The selected answer is completely correct, but something I'd suggest is to NOT use script/runner. The resources required to load the entire stack of your rails application is pretty intense for something to run regularly.
In my past experience, any cron jobs generally only have to deal with data (as opposed to say, generate static files, etc). In this case, you can very simply just load your models up, and since you've written your models the correct way (fat models), you can easily do your data processing with a few model methods.
Of course, all the above depends completely on your task, so take it with a grain of salt :)
I suppose this was a sort of answer to a problem that may not exist, and wasn't asked here, but just thought I'd throw my two cents in ;)
You wouldn't happen to be working on OSX? You should be installing a newer ruby rails and gems off macports instead. Google for the instructions...
As indicated by earlier posts, your Cron is using a different gem command source — also try which gem and gem -v. You may have a library set in your .bash_profile (or similar shell configuration or perhaps by other means, setting proper Ruby/Rails environment (i.e., Locomotive or other all-in-one environment).
To update your gem setup:
gem update --system
More information here - http://www.rubygems.org/read/book/1