search for: delete_worker

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

...from this message http://rubyforge.org/pipermail/backgroundrb-devel/2006-July/000134.html that BackgrounDRb will offer a way to kill a worker from within itself. As this message is from 7/25, I wonder if this feature has been added since. If not, is there any way to do it? I tried this: MiddleMan.delete_worker(@_job_key) But it raise: uninitialized constant MiddleMan - (NameError) Thanks Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060901/c4e742a6/attachment.html

...r << "logging #{Time.now}" sleep 2 end In my secong console I did: tail log/backgroundrb.log -f This is so I could see the line getting added to the log every 2 seconds. Then in my other console I started script/console and created a new worker. Then killed it with MiddleMan.delete_worker(job_key), where job_key was the job key for the worker. After I did that the other console that was monitoring my log continued to add a line every 2 seconds, it didn''t stop. Am I missing something here or shouldn''t deleting a worker stop the loop and kill the thread? Tha...

Hi, First, thanks for the plugin. Sorry if this is not strictly a backgroundrb issue but I thought others on this list might have come across this problem. I''m trying to run the test that comes via the worker generator. The test works fine when running ''rake test_functional'', but when the tests are run by autotest I get "uninitialized constant BackgrounDRb"

Can a worker kill themselves when they''re ''done''? Or do I have to do that either from the controller or the worker manager? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061023/11dd429c/attachment.html

I am using BackgrounDRb to resize images after they are accepted into our system. However, it has become clear that this creates a memory leak. I''m not sure exactly where the leak exists, but I don''t think it''s in my own code as it is presently being used in production and has resized thousands of images without a leak occurring, thanks to calling GC.start

...n completed. Thus, at the end of my do_work, I just call self.delete to (in theory) self-destruct. However, while checking the jobs.size from the console, I''ve noticed that this doesn''t seem to be working. Further, by grabbing the worker keys via jobs.keys, I try to manually call delete_worker to kill them off, and I get a RuntimeError "not beating" from Slave. However, when I call jobs[key].shutdown? to see if the job is dead, it returns false, indicating the the job isn''t "shut down". So, I can''t seem to have the workers self-destruct, and I can...

Hello, Thank you so very much for Backgroundrb. Good Stuff. A general question: Do: - calling ''teminate'' within a worker - calling delete_worker through MiddleMan - letting the :ttl expire - calling MiddleMan.gc! (with an appropriate timestamp) All accomplish the same thing? And here''s a bonus feature request: It''d be cool if you could specify how many instances of a particular worker class can be active at the same time...

I noticed in the BackgroundRB class in the delete_worker method there is a line: if @jobs[key].respond_to? :thread For some reason this is returning false for me, it gets down to this line and returns false, not killing the thread. Any idea why this is returning false? Thanks for your help. Thank You, Ben Johnson E: bjohnson at contuitive.com...

...gt; >> thanks for the reply. >> >> There''s a ruby process that appears in top when I fire off the do_work >> method. >> It uses around 30-50% cpu and disappears once all processing has >> completed. >> >> When I try to stop processing using delete_worker I was expecting this >> ruby process to stop, >> but understand/expect that backgroundrb is still running. >> >> I tried >> MiddleMan[:process_watcher].terminate && MiddleMan.delete_worker >> (:process_watcher) >> however this seems to do less then...

...an old announcement by Ezra, relating to the older version of BackgrounDRb, about workers being able to clean up after themselves and a TTL feature. I''m not sure if these things are present in the newer version. I''ve tried overriding the delete method in my worker but when I call delete_worker, the method doesn''t appear to be called. Is there a right way to do this? If not, could a callback be added? The :ttl option doesn''t appear to be there anymore. With scheduling, does :end actually delete the worker or merely stop making calls to it? If it doesn''t delete,...

Is it expected that MiddleMan.ask_stats will return a status for a worker that has been MiddleMan.delete_worker''ed? The worker isn''t showing up in MiddleMan.query_all_workers, so it seems that is shouldn''t have a status either. Is there a way to define a callback that is called at deletion, to reset the status, or do I need to write my own method to reset the status before I dele...

...nd when you try to access it from rails you get an error because there is no longer a worker at that job key. The kill method is meant to be used within a worker that you fire and forget. If you want to get the results then you should not call kill right in your worker. You can call kill or delete_worker from rails in your done method. So if you want to see the progress bar working I suggest you put a sleep in the while loop. A while loop with no sleep can count to 1200 before you could blink and then the kill method gets called and your screwed. So add sleep 0.3 or somethign within the w...

...s and fixes that addresses much of the issues that we talked about since last couple of days. 1. Use configuration option :debug_log: false to disable backgroundrb_debug.log. 2. As shown below, use lazy_load option to disable aggressive loading of models ( and somewhat stupid too). 3. MiddleMan.delete_worker(:worker => :foo_worker) will now ABORT the worker, it won''t wait for tasks to finish. I am still skeptic about the behavior, but since that was the behavior in older version, I am continuing it. 4. Get information about all running workers: >> MiddleMan.all_worker_info => [{:...

...x.synchronize { job_key = opts[:job_key] || gen_key unless self[job_key] self[job_key] = instantiate_worker(opts[:class]).new(job_key,opts[:args]) self[job_key].start_process return job_key else raise ::BackgrounDRbDuplicateKeyError end } end In MiddleMan::delete_worker(), I''ve added steps where, if the job is still alive, activate the kill signal to the job, and wait for it to clean itself up and activate the :safe_to_kill signal. Then kill it. def delete_worker(key) @mutex.synchronize { if @jobs[key] if (@jobs[key].thread.alive?) @j...

Folks- I just commited another revision of the plugin. Nothing huge in this update but some extra features. Acl lists are now configurable in the config file. So you will want to blow away and recreate your config file again. Thanks to Georg Friedrich for this. And I applied Gunter Ladwig''s patch for singleton worker classes. These are workers that only have one instance of

Hi, it would be nice to be able to specify workers as singletons. By this I mean that every call to the new_worker method returns the same instance of said worker. This can be done transparently either by adding a new argument to new_worker (something like :singleton => true) or adding a new method, like I did in my installation of BackgrounDrb: def get_worker_by_class(klass)

...;', progress_percent) page.redirect_to( :action => ''done'') if progress_percent >= 100 end else redirect_to :action => ''index'' end end def done render :text => "De database is bijgewerkt" MiddleMan.delete_worker(session[:job_key]) end end --------------------lib/workers/get_passwds_worker.rb-------------------- # Put your code that runs your task inside the do_work method it will be # run automatically in a thread. You have access to all of your rails # models. You also get logger and results method in...

Howdy Folks- I''m happy to announce a new release of BackgrounDRb! I have added quite a few new features and included some nice patches from folks on the list. $ script/plugin install svn://rubyforge.org//var/svn/backgroundrb All of the code now stays within the plugin and the start and stop scripts are now just stubs. This makes it easier to tweak or figure out how it works.

Hello, Yesterday I posted about how to email from a worker. I decided to be a bit piggy and just inhale all of rails. Sorted. I am noticing some rather ominous behavior though. The setup: My worker takes an uploaded image as a param and passes it (via system call) to a C++ image processing engine. Take a look at these memory consumption figures for successive runs uploading the identical image