On Feb 20, 2008 2:22 PM, hemant <[EMAIL PROTECTED]> wrote: > But later we changed the code and we thought when you invoke > delete_worker, your worker should exit immediately and request to kill > a worker shouldn't be queued. > > In current code, apart from executing "delete_worker" another way to > kill workers is to call "exit" from inside of a worker. This will give > you opportunity to do proper cleanup and stuff. > I am not sure, if this is what you want, but "delete_worker" is like > "kill -9 " of unix. > > So, if you want to handle graceful exit, call exit from worker code > itself. >
Thanks for your reply. So how would I be able to signal to the worker that it should call exit? I guess that is the challenge. The worker is involved in a large batch job, and I need to be able to send a message to it to tell it to kill itself. I had hacked out an approach using both a database table in which it would check for the existence of a certain row, and if there remove and kill itself, but I wondered if the framework itself provided a better way? Also, assuming I just continue to use delete_worker in the way I am today, is there any way possible to delete the last status the worker reported? Thanks for your help! John
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
