exit() should work as before. I apologize if the behavior is broken, I will try to reproduce and fix.
On Mon, Apr 27, 2009 at 3:44 PM, Meyers, Dan <[email protected]>wrote: > We've got some backgroundrb workers that we want to start at some point > after backgroundrb has been started, and exit as soon as they've > finished their task. The starting works fine and reliably, using: > > MiddleMan.new_worker(:worker => worker, :worker_key => jobkey) > MiddleMan.worker(worker, jobkey).async_wrapper(:job_key => jobkey, :arg > => task.id) > > worker and jobkey are both extracted from our database table of jobs to > be run. > > When using the previous version of backgroundrb we were just calling > exit at the end of execution in those workers that we wanted to die once > they'd done their work. However this now results in: > > Error calling method wrapper with 516 on worker scanner_worker > exit > /usr/data/nac_development/rails/lib/nac_worker.rb:84:in `exit' > /usr/data/nac_development/rails/lib/nac_worker.rb:84:in `wrapper' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:313:in `send' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:313:in `invoke_user_method' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:245:in `process_request' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:219:in `receive_data' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:209:in `receive_internal_data' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _parser.rb:44:in `extract' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _parser.rb:26:in `loop' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _parser.rb:26:in `extract' > /usr/data/nac_development/rails/vendor/plugins/backgroundrb/server/lib/m > eta_worker.rb:207:in `receive_internal_data' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _worker.rb:55:in `handle_internal_messages' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:194:in `handle_read_event' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:192:in `each' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:192:in `handle_read_event' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:146:in `start_reactor' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:139:in `loop' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _core.rb:139:in `start_reactor' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/../lib/packet/packet > _worker.rb:20:in `start_worker' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner > :33:in `load_worker' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner > :26:in `initialize' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner > :47:in `new' > /usr/local/lib/ruby/gems/1.8/gems/packet-0.1.15/bin/packet_worker_runner > :47 > /usr/local/bin/packet_worker_runner:19:in `load' > /usr/local/bin/packet_worker_runner:19 > > After some checking online, we tried moving to using: > > MiddleMan.worker(worker_name, job_key).delete > > at the end of the worker after it had finished all work. This seems to > work, but only about half the time. Sometimes the worker process will > die, and can no longer be seen in the process list, but sometimes it > continues to sit there after the worker has finished doing all it's > work. If the worker is re-run using the same job key it will run fine > again using the same process and the process will sometimes then be > removed correctly, but of course the expected operation on our live > system is that a lot of these workers will never be run twice with the > same job key, as we want the ability to run many concurrently. As such > we would end up with hundreds of erroneous worker processes from > backgroundrb. We never used to get unkilled workers using the old > version of backgroundrb, so I feel safe in assuming this is some issue > with the delete method rather than our worker's code. > > I am assuming that I am doing something wrong in my deletion here. What > should I be doing to reliably exit/kill a worker from within itself once > it has finied executing it's designated task? > > Thanks in advance. > > -- > Dan Meyers > Network Specialist, Lancaster University > E-Mail: [email protected] > > > _______________________________________________ > Backgroundrb-devel mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
