Script/runner inside BackgrounDRb worker

Joe Peck wrote the following on 09.07.2007 17:05 :

How can I do this?

When I try "rake backgroundrb:start" now, I get this error: /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': /home/joe/projects/edu/config/../script/backgroundrb/../../config/../lib/workers/mailman_worker.rb:14: syntax error, unexpected tSTRING_BEG, expecting kDO or '{' or '(' (SyntaxError)     script/runner 'MailQueue.process' -e development

Here is my worker: class MailmanWorker < BackgrounDRb::Rails

  repeat_every 5.minutes   first_run Time.now

  def do_work(args)     ## This will send all the emails in the queued_mails table     script/runner 'MailQueue.process' -e development    You are trying a syntax fitted for a shell script in a ruby script...

Just use "MailQueue.process".

    kill()    Not sure what it is supposed to do (but I'm not familiar with BackgrounDRB).

  end

end

Anyway, as the cron-like features of BackgrounDRB are reported to be highly unstable, you'd probably just use cron (and in this case you'll have to use your original syntax with script/runner)

Good luck,

Lionel

I haven’t heard anything bad about the BackgrounDRB cron features. I was actually going to switch over to it… Where did you read that the cron feature was unstable? Thanks, Ben

Ben Mabey wrote the following on 09.07.2007 22:31 :

I haven't heard anything bad about the BackgrounDRB cron features. I was actually going to switch over to it... Where did you read that the cron feature was unstable? Thanks, Ben

Posts on the backgroundrb-devel mailing-list. http://rubyforge.org/pipermail/backgroundrb-devel/2007-June/000915.html

It seems cron-like feature could fit in backgroundrb but are not yet stable.

I always read the -users and -devel lists before deciding to use software in production and backgroundrb is on my radar since some time...

Regards,

Lionel

As I've posted problems with brb here before, so it's apropos that I note a solution I've found to an instability.

I've found that within (potentially) very short running processes putting a sleep 5 (or so) at the beginning seems to clean up internal brb crashes; perhaps not all, but I'm now smiling much more. Brb has now been running 3 days without failure. Not putting the worker to sleep would result in 2-3 crashes per 24 hours.

When I can free up a few days I'll likely dig into brb myself.

cheers,

Jodi

Yeah unfortunately I haven't had any time to work on bdrb in a long time. I am going to put a call out for a new maintainer as I will not have time to support the library properly in the future. It's got aq good start to being a great project so if anyone wants to step up and take over as maintainer I'd be happy to help wityh the process.

Cheers- -- Ezra Zygmuntowicz-- Lead Rails Evangelist -- ez@engineyard.com -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273)