similar to: Tasks get executed twice with repeat_every

Ezra, Sorry for inundating the list. In using the autostart, repeat_every, and first_run, I noticed a behaviour I didn''t expect. I would like the job to run starting at 2am, and then every 24 hours. So I set first_run to Time.now.beginning_of_day + 2.hours, and repeat_every to 24.hours. The problem is if backgroundrb starts up at 6am (due to a code change or server bump), then the

I''m just starting out with BackgrounDRB and I''m pretty excited. I know there''s some development going on, but would patches against the released code be welcome? Nothing profound, just some documentation errors. Now for the real reason I''m writing. I''m testing the new(ish) repeat_every code and it appears to be having a problem. I''ve got a

If I use repeat_every for a worker, if the do_work function has not completed by the time the next interval rolls around, will a new thread be started, resulting in 2 threads for the same worker? Looking at start_process, it seems like the thread gets created (which spins off the thread and then continues to execute the start_process method, right?), then sets the @next_start. So if the

Hello all, I''ve got the problem about the following simple application using autostart and repeat_every. A thread(?) is forked for processing task at first, but at sencond time two threads seem to be forked. My simple application code is... - In worker class class FooWorker < BackgrounDRb:Rails repeat_every 2.minutes first_run Time.now def do_work puts Time.now.to_s +

Hello all, I am interested in using BackgrounDRb to clear out ActiveRecord based sessions. I have this working, just with a small hitch, here is the code: class ClearSessionsWorker < BackgrounDRb::Rails repeat_every 7.minutes first_run Time.now def do_work(args) Session.destroy_all(["updated_at < ?", 20.minute.ago ]) end end It''s not very complicated and

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

First off BackgroundRb rocks!!!!. Top marks Ezra, it''s gone a long way to stopping us from doing a nasty curl/cron hack :) Okay so here''s what we''re using it for. We''re synchronising data from a Filemaker database, via web service equest, into a mysql database via a rails model called ''Syncer'' [How''s that for an oddball use case!].

Hey. I have a very annoying problem, and was wondering what is wrong. Suppose I have backgroundrb running, and then I have an action in some controller. In the action I define a worker. When leaving the action, suddenly the connection to backgroundrb is lost: DRb URI: druby://localhost:22222 Pid: 3976 Autostart... done druby://localhost:42531 - #<Errno::EBADF: Bad file descriptor -

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

Hello, i need to have some jobs scheduled in the background and executed at specific times. I wanted to make a worker who does that - and it works a little bit - but i had an enlightment... why not make bgdrb itself play that role? i mean, the MiddleMan has already everything needed! a timer thread, currently used only for deleting old workers and the workers itself. since im not familiar with

I''m having trouble getting backgroundrb up and running in a production environment. Here''s my backgroundrb.yml: --- port: "22222" timer_sleep: 60 load_rails: true environment: production host: XXX.XX.XXX.50 database_yml: config/database.yml acl: deny: all allow: localhost 127.0.0.1 XXX.XX.XXX.51 order: deny,allow I start BackgroundRB from XXX.XX.XXX.50 with

Hi all, I just read Ezra''s article on BackgroundRb and decided to use it one of my projects. I installed the plugin into my rails project using script/plugin and then ran rake backgroundrb:setup to copy the yml scripts. Now my backgroundrb.yml looks like ======= --- port: "22222" timer_sleep: 60 load_rails: true environment: development host: localhost database_yml:

Hi, I''m not much of a developer but I''ve been using backgroundrb for a while now and with the release of 0.2.1 it looks like I can finally upgrade from the old version (0.2.0 had some weird issues when jobs just wouldn''t run, seems to have cleared up now - Thanks!). Anyhow, while I''m doing this, I would like to tackle this problem. Most tasks I run in

I am new to this list and relatively new to the backgroundrb plugin,. So first i will say hello to everybody here, especially to Ezra Zygmuntowicz! I played a little bit with a dummy worker and so far everything worked well. But now i want to do real work in a worker but now i get that error[1]. It looks like that the constants configured in environment* configs are not available to the worker

i ran rake backgroundrb:setup and modified the default config/backgroundrb.yml file as: --- port: "22223" timer_sleep: 60 load_rails: true environment: production host: localhost database_yml: config/database.yml acl: deny: all allow: localhost 127.0.0.1 order: deny,allow and my database.yml production: adapter: mysql database: chip2_production username: xxxxx password:

I have a job that I am starting from a Rails controller in production mode using MiddleMan: MiddleMan.new_worker(:class => :import_ccg_category_worker, :args => { :category_id => @category.id, :remote_category_id => params[:remote_category_id], :description => "Importing CCG products for #{@ category.name}" }) Both of the category ID variables are just basic integers. I

Hello Folks- I am really happy to announce the release of BackgrounDRb 0.2.0 . This is a complete rewrite and re-architecture of this codebase. I want to thank skaar for all of his hard work. I put out a call for help with the new architecture and skaar stepped up bigtime. I had already written the new scheduler and cron compatible syntax and moved to multi process architecture. But he

I''m trying to do the tutorial at http://www.infoq.com/articles/BackgrounDRb. A little more than half-way through it says "Upon instalation, the plugin writes a config file into RAILS_ROOT/config/backgroundrb.yml." It didn''t happen for me. I installed the plugin with: ruby script\plugin install svn:\\rubyforge.org//var/svn/backgroundrb It added a bunch of files,

I have a scheduled worker that runs every minute, checking for new eBay auctions to post. If it finds an auction, then it posts it. If there are no auctions in the database that are queued up, it simply does nothing. I got the worker to finally run as a scheduled worker, every minute. However, after about 30-45 scheduled runs, it simply stops running. My backgroundrb_schedules.yml file: ------

If you''re in a timezone with an abbreviation that map to more than one timezone (eg, CST), first_run may not work as you expect it to. Witness: $ irb -r time irb(main):001:0> Time.now => Wed Oct 04 20:37:24 CST 2006 irb(main):002:0> Time.parse(Time.now.to_s) => Thu Oct 05 10:37:30 CST 2006 Notice the 14 extra hours... Time.parse converted the time thinking CST meant -06:00