similar to: backgroundrb and autotest

> On Jul 30, 2006, at 5:11 PM, Chris H wrote: > >> Hi Ezra, >> >> 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

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 the list people, hi Ezra, I just read 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

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

Hi, Does it make sense to test a worker class by calling Middleman.new_worker? Or should I just be testing the functionality in the do_work method, with, say, a mock object. This seems like a really ugly DRY violation: you''d need to keep the code in the mock and the real worker in sync. That''s the philosophical half of my question. In fact, until someone tells me why I

OK I know whats happening. Your while loop completes and calls kill on the worker before your task_progress controller method ever gets called> So the worker is deleted and 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

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, 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

Hi all, I''m a newbie to backgroundrb and am having trouble integrating it into my rails-app. I''m using namespaces to differentiate between the parts of my app. When I want to create a new worker, it seems that it cannot find the worker object. Here''s my code: -------------------- controller app/passwd/index -------------------- class Passwd::IndexController <

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

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

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

Hey all, Been reading through all the old posts (and the docs) to familiarize myself but I still feel a bit lost. I''m on trunk and am having a bit of a hard time knowing where to start with the particular I''m trying to solve. So far, I''ve downloaded backgroundrb, done the basic rails setup, created my worker and started it using `script/backgroundrb start`.

Hey all, Quick question about handling completed workers... Most of my workers are one-offs that just let me spin off a long-running file transfer process and then they just need to self-destruct when 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

I made a worker that run an infinite loop and does the following: while true @logger << "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

Hi, I am pushing some updates 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

Friends- I''m happy to annouce the first alpa release of BackgrounDRb. This is a small framework for managing long running background tasks that allows for ajax progress bars and more. It also serves as an Application wide cache and context store for when you need something like sessions but shared between users and multiple backend processes like fcgi''s or mongrels.

Is there something special I need to do to access session data in a worker? I''m using an AR session store. I''ve been working with Ezra''s tutorial, modifying it a little here and there to figure it out. So I changed the progress bar to a simple count-down in the worker which sends back the count to display in the view. No big deal. But if I try to access session

Sorry to be such a bother but I''m not getting this. I have two models: Emrec and Session (I''m using AR for session mgmt.) In my worker I can access the Emrec model and delete a record, AS LONG AS I don''t try to access the Session model. With the Session model access commented out as below, the Emrec record gets deleted. If I uncomment those lines, the Emrec