[Backgroundrb-devel] Exiting worker from within itself

Meyers, Dan d.meyers at lancaster.ac.uk
Mon Apr 27 06:14:24 EDT 2009


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: d.meyers at lancaster.ac.uk




More information about the Backgroundrb-devel mailing list