similar to: Zombies?

Hey all, I''m having some issues moving a project that incorporates Backgroundrb onto a staging server... For some reason (surely of my own doing), my RailsBase workers are insisting on using trying to access my development DB instead of my "production" DB. When I try to load a model object from within a worker, I get the following: 20061120-21:54:28 (26296)

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

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"

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

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

Hi Ezra/skaar, Wow man, the exercise was worth it. The connection closed problem with socket as i mentioned in my earlier mails...completely disappeared, and now i can connect only once to the socket and keep reading..till end of its days. Literally impossible with older release of backgroundrb. This could also potentially solve the issues people were having with ActiveRecord. As i said

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

Hello. I read in 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

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

Hi there, Backgroundrb is working pretty well for me but I have a job that launches two of the same job, apparently a minute(?) apart from each other. Should this be happening if I have repeat interval enabled with a job_key? It seems like it should wait until the job is finished before launching a new instance. --Backgroundrb_schedules.yml-- city_updater: :class: :city_updater_worker

Hi, I''m using backgroundrb 0.2.1 in a production environment and for most parts I''m very happy. We are using it to do some heavy video editing on the server side and it works great except that under, what seems heavy load the below problem happens intermittently. The problem has only happened 5 times out of over 500 runs by our backgroundrb worker. This is the code in our

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

I am sure..again I am missing something, but I am trying to start a worker, when backgroundrb starts and it doesn''t seem to work. Here is my config/backgroundrb_schedules.yml file: feed_worker: class: feed_worker job_key: feed_worker_key worker_method: do_work trigger_args: repeat_interval: 20.minutes I even tried this from Rails controller: # def start_feed_worker #

so i have an after_create method on my track model that kicks off a background process that converts an mp3 to a swf. this is working fine locally on my machine, but upon moving it to my production server, i am getting the following error. I''ve only been using backgroundRB for like 48 hours, so i''m not really sure what this means or where to go. any ideas?

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

I''m running the latest backgroundrb mainly for scheduled tasks support. As per the documentation I created the backgroundrb_schedules.yml with the following: simple_label: :class: :document_sorter_worker :worker_method: :do_work :job: :bleh :trigger_args: :start: <%= Time.now + 5.seconds %> :end: <%= Time.now + 10.minutes :repeat_interval: 1.minute Under

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