On Feb 20, 2008 2:39 PM, hemant <[EMAIL PROTECTED]> wrote: > On Thu, Feb 21, 2008 at 1:02 AM, John Wells <[EMAIL PROTECTED]> > wrote: > > > > > > 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? > > > > Something like this: > > class FooWorker < BackgrounDRb::MetaWorker > def some_work(args = nil) > # do some job processing from database > exit > end > end
Ok, but when would exit be called here? After all the work is done? I guess what I want is a kill -9 functionality, but with the ability to at the very least clear the worker's status...
_______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
