search for: repeat_everi

I have a simple worker that I set up with repeat_every: class DueNoteQueuerWorker < BackgrounDRb::Rails repeat_every 1.minutes first_run Time.now def do_work(args) @logger.debug("Sending due notes. The current time is #{Time.now}") end end I want this to run every minute, all the time. The first run is fine, but it seems that subsequent runs get executed

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

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

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 +

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

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 -

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

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!].

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

Hey Greg- Yes I am sorry, the new architecture uses fork and named pipes and a bunch of unix stuff to do its magick. Now you may be able to port it to qwork on windows, but I don''t think it is possible :( I''m really sorry about this but I need this thing to be as robust and solid as it can be and in the end windows isn''t compatible. Now you may be able to