I thought I could delete a busy worker by calling MiddleMan.delete_worker, but doesn''t seem to end. I believe this was possible in 0.2, is it not in 1.0? thanks, Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/0c701f29/attachment.html
Hi, I think there has been some changes in the arguments, the following is working fine for me. MiddleMan.delete_worker(:worker => :example_worker, :job_key => :that_long_process) Rai On Jan 3, 2008, at 8:17 PM, Zachary Powell wrote:> I thought I could delete a busy worker by calling > MiddleMan.delete_worker, but doesn''t seem to end. I believe this was > possible in 0.2, is it not in 1.0? > > thanks, > Zach > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
This worker doesn''t have a key, so that makes no difference... I''ve tried making a test method which just does sleep(60) and I can''t kill that either (with or without key).. Its strange, I thought it worked when I first migrated over, maybe it doesn''t work since 299 (I noticed it now saves statuses after the worker is deleted, so it could be related to that perhaps - if it is a bug). On 1/3/08, Raimond Garcia <voodoorai2000 at gmail.com> wrote:> > Hi, I think there has been some changes in the arguments, the > following is working fine for me. > > MiddleMan.delete_worker(:worker => :example_worker, :job_key > => :that_long_process) > > Rai > > On Jan 3, 2008, at 8:17 PM, Zachary Powell wrote: > > > I thought I could delete a busy worker by calling > > MiddleMan.delete_worker, but doesn''t seem to end. I believe this was > > possible in 0.2, is it not in 1.0? > > > > thanks, > > Zach > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/00b3e7aa/attachment.html
Hmmm, check out the examples folder inside vendor/plugins/ backgroundrb, that helped me get everything up and running with the new version. Rai On Jan 3, 2008, at 9:03 PM, Zachary Powell wrote:> This worker doesn''t have a key, so that makes no difference... I''ve > tried making a test method which just does sleep(60) and I can''t > kill that either (with or without key).. Its strange, I thought it > worked when I first migrated over, maybe it doesn''t work since 299 > (I noticed it now saves statuses after the worker is deleted, so it > could be related to that perhaps - if it is a bug). > > On 1/3/08, Raimond Garcia <voodoorai2000 at gmail.com> wrote: > Hi, I think there has been some changes in the arguments, the > following is working fine for me. > > MiddleMan.delete_worker(:worker => :example_worker, :job_key > => :that_long_process) > > Rai > > On Jan 3, 2008, at 8:17 PM, Zachary Powell wrote: > > > I thought I could delete a busy worker by calling > > MiddleMan.delete_worker, but doesn''t seem to end. I believe this was > > possible in 0.2, is it not in 1.0? > > > > thanks, > > Zach > > _______________________________________________ > > Backgroundrb-devel mailing list > > Backgroundrb-devel at rubyforge.org > > http://rubyforge.org/mailman/listinfo/backgroundrb-devel > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/c525cc7f/attachment.html
I''m experiencing this, too. I can delete a worker after it''s finished it''s finished executing a particular ask_work with :worker_method call, but I can''t "abort" the worker early if I want to interrupt execution of ask_work. I do call delete_worker with both the :worker and :job_key specified. So I second Zach''s problem. Cheers, Walter On Jan 4, 2008, at 9:10 AM, Raimond Garcia wrote:> Hmmm, check out the examples folder inside vendor/plugins/ > backgroundrb, that helped me get everything up and running with the > new version. > > Rai > > On Jan 3, 2008, at 9:03 PM, Zachary Powell wrote: > >> This worker doesn''t have a key, so that makes no difference... I''ve >> tried making a test method which just does sleep(60) and I can''t >> kill that either (with or without key).. Its strange, I thought it >> worked when I first migrated over, maybe it doesn''t work since 299 >> (I noticed it now saves statuses after the worker is deleted, so it >> could be related to that perhaps - if it is a bug). >> >> On 1/3/08, Raimond Garcia <voodoorai2000 at gmail.com> wrote: >> Hi, I think there has been some changes in the arguments, the >> following is working fine for me. >> >> MiddleMan.delete_worker(:worker => :example_worker, :job_key >> => :that_long_process) >> >> Rai >> >> On Jan 3, 2008, at 8:17 PM, Zachary Powell wrote: >> >> > I thought I could delete a busy worker by calling >> > MiddleMan.delete_worker, but doesn''t seem to end. I believe this >> was >> > possible in 0.2, is it not in 1.0? >> > >> > thanks, >> > Zach >> > _______________________________________________ >> > Backgroundrb-devel mailing list >> > Backgroundrb-devel at rubyforge.org >> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> >> _______________________________________________ >> Backgroundrb-devel mailing list >> Backgroundrb-devel at rubyforge.org >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel >> > > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080104/8bdd1901/attachment.html
On Jan 4, 2008 2:10 AM, Walter McGinnis <walter at katipo.co.nz> wrote:> I''m experiencing this, too. I can delete a worker after it''s finished it''s > finished executing a particular ask_work with :worker_method call, but I > can''t "abort" the worker early if I want to interrupt execution of ask_work. > > I do call delete_worker with both the :worker and :job_key specified. > > So I second Zach''s problem. >When you invoke MiddleMan.delete_worker(), you are actually calling "exit" from within the worker. Thats the current implementation, and by default your requests are queued and hence "exit" is not invoked until, whatever worker is doing is finished. And hence the behavior. But this can be changed and master can explicitly terminate a worker, since it has process id of each worker, so will that be a more desirable behavior? -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
On Jan 4, 2008, at 10:37 AM, hemant wrote:> On Jan 4, 2008 2:10 AM, Walter McGinnis <walter at katipo.co.nz> wrote: >> I''m experiencing this, too. I can delete a worker after it''s >> finished it''s >> finished executing a particular ask_work with :worker_method call, >> but I >> can''t "abort" the worker early if I want to interrupt execution of >> ask_work. >> >> I do call delete_worker with both the :worker and :job_key specified. >> >> So I second Zach''s problem. >> > > When you invoke MiddleMan.delete_worker(), you are actually calling > "exit" from within the worker. Thats the current implementation, and > by default your requests are queued and hence "exit" is not invoked > until, whatever worker is doing is finished. And hence the behavior. > But this can be changed and master can explicitly terminate a worker, > since it has process id of each worker, so will that be a more > desirable behavior? >For me it would be, yes. I can''t speak for others. Cheers, Walter
For me it would be best (that''s how the previous version worked) - though presumably there''d be an easy way to do both. (delete_worker() or kill_worker() etc). thanks. On 1/3/08, Walter McGinnis <walter at katipo.co.nz> wrote:> > > On Jan 4, 2008, at 10:37 AM, hemant wrote: > > > On Jan 4, 2008 2:10 AM, Walter McGinnis <walter at katipo.co.nz> wrote: > >> I''m experiencing this, too. I can delete a worker after it''s > >> finished it''s > >> finished executing a particular ask_work with :worker_method call, > >> but I > >> can''t "abort" the worker early if I want to interrupt execution of > >> ask_work. > >> > >> I do call delete_worker with both the :worker and :job_key specified. > >> > >> So I second Zach''s problem. > >> > > > > When you invoke MiddleMan.delete_worker(), you are actually calling > > "exit" from within the worker. Thats the current implementation, and > > by default your requests are queued and hence "exit" is not invoked > > until, whatever worker is doing is finished. And hence the behavior. > > But this can be changed and master can explicitly terminate a worker, > > since it has process id of each worker, so will that be a more > > desirable behavior? > > > > For me it would be, yes. I can''t speak for others. > > Cheers, > Walter > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080103/844589c5/attachment-0001.html