On Wed, Feb 20, 2008 at 11:50 PM, John Wells <[EMAIL PROTECTED]> wrote: > > > > On Feb 18, 2008 12:59 PM, John Wells <[EMAIL PROTECTED]> wrote: > > > > > > This seems to work, but there are a few undesired things left dangling, as > I haven't found a way to "catch" the delete request and do a cleanup. > Assuming this is impossible, is there any way to clear the last status > registered by the worker with register_status if that worker is deleted? > > > > And, is the above the proper way of cancelling work? > > > > Thanks very much for your help! > > > > Sorry to bump my own message, but I'm still very interested in learning if > I'm approaching the above properly, and if there's a way to clear a worker's > status when that worker is deleted. >
Hmm, No problems. The way you are deleting/canceling running workers is correct. But apparently, you want a callback, which should be invoked when worker dies, so you can cleanup stuff. Now, unfortunately this means that like all requests, request to kill a worker must be handled by the worker itself, but if a worker is going to handle a request to kill itself ( in another words calls "exit" from inside worker code ), then when you invoke: MiddleMan.delete_worker and worker is doing some processing then worker won't handle delete_worker request until its done with processing whatever its doing. That was how "delete_worker" used to work earlier. I mean when you invoke delete_worker it used to invoke "exit" method on worker and worker used to exit as usual. 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. _______________________________________________ Backgroundrb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/backgroundrb-devel
