How to run 'resque:work' rake task from rails application? - ruby-on-rails

Having followed the rails-cast (http://railscasts.com/episodes/271-resque?view=comments), I was able to setup my rails application similarly with worker and rake tasks.
However, as specified in the rails-cast, once I start my rails server, I have to issue the following command in a separate terminal window:
TERM_CHILD=1 QUEUES=* rake resque:work
This gets me up-and-running and I have no issues. However, instead of firing off a rake command on terminal (or writing a startup shell script), I would like to issue this terminal command (TERM_CHILD=1 QUEUES=* rake resque:work) from Rails itself when the application starts up so its available during the duration of the application's uptime on the server.
I am in the process of learning Rails framework so I would greatly appreciate if you can give me some help and let me know how/where to place any code snippet you may provide me with.
Thank you very much in advance.
Here are my environment specs:
I am using jruby (jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64])
Rails version 4.1.8
I am developing on LINUX ubuntu 14.04
I will be deploying this application to Windows 2008 server on a Tomcat server as a WAR package
I am using PostgreSQL as my database.

That approach would make it difficult to turn off your resque workers. I recommend using a common gem called foreman to handle this. I'll let you look a the documentation, but your Procfile would look something like:
web: rails s -p $PORT
resque: TERM_CHILD=1 QUEUES=* rake resque:work
And you would be able to start both rails and resque by just running the foreman command in console. That will also allow you to exit out of both easily.
Updated per OP's message:
require 'resque/tasks'
ENV['TERM_CHILD'] = 1
ENV['QUEUES'] = '*'
Thread.new { Rake::Task["resque:work"] }
The Thread.new is there because it would otherwise cause the rest of the app to never load.

Related

How to configure Solr standalone in Production server with Rails application using sunspot gem?

I'm looking to deploy solr-8 in production as standalone mode with Ruby on Rails application. While running bundle exec rake sunspot:solr:reindex getting this error
RSolr::Error::Http - 500 Internal Server Error
Any help would be appreciated!
using gem sunspot in development and is working fine with standalone solr-8 on local machine.
Solr is running in cloud mode. Please share the configuration which is used to talk to solr and rails for index
It's really straight forward setup but took long time for me to resolve.
In standalone mode it is bit tricky to communicate with rails
we need to copy schema.xml and solrconfig.xml to server/solr/your-core/conf/
as Solr-8 have some deprecation warning. Please carefully read warnings.
Once you copied files restart solr and run
rake sunspot:solr:reindex

Running two server at the same time with a script(Ruby and Rails)

I am new new to Ruby on Rails.
In my rails rails application I have used the two servers. One is the rails server and other one is simple ruby server.rb file. I need to start both the server with Start.sh script to deploy.
I have tried the following Code of Start.sh file. But the issue is Rail server is not starting until and unless I stop the ruby server.rb.
start.sh file code
rake ts:stop
rake ts:start
rake ts:index
ruby server.rb
rails server
I want to run both the servers through a single script
If you are on a unix based system adding an & will start a command in the background. What you need is:
rake ts:stop
rake ts:start
rake ts:index
ruby server.rb &
rails server
For a rails project the better way to start multiple processes is to use a Procfile. Then you would start your application using a Procfile manager like foreman https://github.com/ddollar/foreman

Can I run Solr server without running rake command for rails application?

Is there any alternate way for running solr server without running rake command for rails application like providing all those solr related classes into single jar and then use that jar.
Please suggest some of the solutions regarding this
Thanks
I don't know if you checked Sunspot (the best haha), but you can use the start/stop commands, for example: https://github.com/sunspot/sunspot#sunspot_rails
bundle exec sunspot-solr start -p 8983
Also check this out for an example https://gist.github.com/doitian/1795439 (integrates Sunspot with Capistrano, but you can get an idea of the implementation)

Delay Job Worker keeps turning off?

New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.

How to create a Heroku rails dev environment in actual development mode?

I'm attempting to mimic, as close as possible, the Heroku deployment environment but in actual development mode for a Rails app. In other words, I'd like more verbose output from the thin console logs web and worker processes and I'd like for the assets pipeline to be refreshed appropriately vs having to run a command to refresh them.
The reason I have to do this is due to some testing of additional workers that need to function during development and testing phases.
Currently I have foreman running a procfile locally which spawns thin. Here are the commands that it steps through:
First I start it via Foreman with RACK_ENV=development PORT=3000 foreman start --port $PORT
Second, in my Procfile I have:
`web: bundle exec thin start -p $PORT -e $RACK_ENV`
`worker: bundle exec ruby worker.rb`
These execute just fine, however I have two seeming problems that I'd like to overcome:
A) I have to run bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile so it seems as though thin does not honor a development mode that does not require asset precompilation. I tried to add config.assets.compile = true into my config/environments/development.rb, but that did not seemingly help the situation. The real problem seems to be that actual images in the assets folder are not refreshed without this manual preocompile step.
B) I am not seeing any more verbose development level logging in the output console. I would like to see a verbose request log as well as the debug print statements that I have in my worker script. None of these propagate back up to the console log where the foreman command is initially run.
The thought has come to mind that perhaps I should just have a Procfile.development and in there have webrick instead of thin, however that only resolves point A and leaves the question of point B above.
Thus my question, how can I accomplish my original designs using foreman + thin?
I ended up approaching this at a little different slant and got through the issue. The core problem I was having was the the logging facility was being overridden by one of gem's we've been using and therefore had to force logging to use the Rails logger with more verbosity:
How to increase Heroku log drain verbosity to include all Rails app details?

Resources