[Backgroundrb-devel] Canceling work...
lists at sourceillustrated.com
Wed Feb 20 14:51:05 EST 2008
On Feb 20, 2008 2:39 PM, hemant <gethemant at gmail.com> wrote:
> On Thu, Feb 21, 2008 at 1:02 AM, John Wells <lists at sourceillustrated.com>
> > On Feb 20, 2008 2:22 PM, hemant <gethemant at gmail.com> 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?
> > guess that is the challenge. The worker is involved in a large batch
> > and I need to be able to send a message to it to tell it to kill itself.
> > 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
> > 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
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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Backgroundrb-devel