Skip to main content

How to kill old Resque workers and don't loose your face

In first thought trivial problem, `god gem` is keeping your Resque workers busy and when you deploy it just ask `god` to kill them by: god remove {group_name}. This is prety common misunderstanding thinking that workers will stop running at same moment, some of them can even live forever trying to establish their life inside your production server and continiously eating memory. One of walkarounds looked like this:

in resque.rake create new task

namespace :resque

task :restart => :environment do

   pids = Resque.workers.map(&:worker_pids) || []
   pids.uniq!
   if pids.any?
       system("sudo kill -QUIT #{pids.join(' ')}")
       puts "killed: #{pids.join(' ')}"
   else
       puts "resque wasn't running: #{pids.join(' ')}"
   end
end

end

It worked fine till one moment when rake stopped running initilizers before task and that cause ugly(hard) to find error. My idea that I think is more beautiful in kind of way that you don't actually not rely on libraries of Resque in moment you try to make Redis stop playing around with workers.

1) modify your resque.god file

worker[:num_workers].to_i.times do |num|
    God.watch do |w|
w.name = "resque-#{$env}-#{queues.split(',').join(':')}-#{num}"
w.group = "resque:#{$env}"
        w.interval = 30.seconds w.dir = "/var/www/app/#{$env}/current"
w.log = "/var/www/app/#{$env}/current/log/resque_workers.log"
w.uid = 'deployer'
w.gid = 'deployer'
w.env = {"QUEUE" => "#{queues}", "RAILS_ENV" => $env}
w.start = "rake resque:work PIDFILE=/tmp/resqueworkers_#{num}" #make worker save his PID in tmp

.....

2) now modify your rake task to 

task :restart => :environment do
    system("sudo for i in `ls /tmp/| grep resqueworkers_`; do kill -9 `cat /tmp/$i`; done");

end

 

And now add this task in your deployment process before reloading `god` config file. Good luck.

 

Comments

Popular posts from this blog

Why Magento sucks?!

p.p1 {margin: 0.0px 0.0px 13.0px 0.0px; font: 13.0px Arial; color: #1022a3} p.p2 {margin: 0.0px 0.0px 13.0px 0.0px; font: 13.0px Arial} p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial} p.p4 {margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial; min-height: 15.0px} span.s1 {letter-spacing: 0.0px color: #000000} span.s2 {text-decoration: underline ; letter-spacing: 0.0px} span.s3 {letter-spacing: 0.0px} span.s4 {text-decoration: underline ; letter-spacing: 0.0px color: #1022a3} This post was inspired by  http://www.commercestyle.com/e-commerce/magneto-sucks I don't agree on everything that wrote there, I won't say that is so sucky and hard. It's childish way to say system is too complicated, read the f**king manual, omg is this so hard?! So from perspective technical guy that have a lot of finished high loaded projects on the back, I want to explain my "sucky" point about it.  1) The thing that bothers me for last few weeks is news about Magento acquir

Magento API + Java != Friends

Recently I've had a task to write small integration of Java to the Magento API, and meet a lot of troubles on the way. First of all Magento supports SOAP web-services that actually don't work well, I've found one solution http://code.google.com/p/magja I didn't tried because we spend much time trying to make them work with no result, so next was XML RPC based API that worked quite well on PHP examples, but caused more trubles. Login worked pretty well: XmlRpcClientConfigImpl config = new XmlRpcClientConfigImpl(); config.setServerURL(new URL("http://magento.dev/index.php/api/xmlrpc/")); XmlRpcClient client = new XmlRpcClient(); client.setConfig(config); Vector params = new Vector(); params.addElement( "defsan" ); params.addElement("123456"); String session = (String)client.execute( "login", params ); But other call's did worked, instead they show: Exception