similar to: Worker cleanup and TTL

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

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

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

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

> 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 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 -------------- next part -------------- An

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

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

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

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

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"

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

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

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 <

I've added an introduction article about the ARA on my web site http://www.voip-forum.com/ The same text is now also added to CVS head as README.realtime. On the same site, you will also find the news item about how we used Asterisk for a call from an airline jet above Greenland to Stockholm, Sweden. The world is getting smaller and more connected every day! /Olle

I''m using backgroundrb for session management and deletion of visitor-entered information when a session is abandoned. The visitor can either click a button to end their session and remove their data, or backgroundrb will do it for them after 5 minutes of inactivity. Everything''s working fine, I think. If the visitor explicitly logs out, then when the worker checks for their

Phil Wyett <philwyett at aura-tech-systems.co.uk> wrote: >Could you be more specific about your issue? Does the webcam get >detected? if you use 'cheese' do you get any errors in say 'dmesg'? > >There has been a webcam issue of late that seems to trace back to a >regression with the latest kernels. This was fixed in the centos plus >kernel, but there is a

On Thu, Aug 27, 2015 at 08:12:11PM +0300, Roman Kagan wrote: > On Thu, Aug 27, 2015 at 03:50:11PM +0100, Richard W.M. Jones wrote: > > On Tue, Aug 11, 2015 at 08:00:20PM +0300, Roman Kagan wrote: > > > debub_gc (coming from the command line) indicates that gc should be > > > forced on program exit. Instead of sticking it on every exit path, > > > register it as