[Backgroundrb-devel] periodic scheduling

Jack Nutting jnutting at gmail.com
Thu Jan 17 12:00:05 EST 2008

I've been using backgroundrb since back in March 2007 or so.  It's
been working mostly OK for me, but since the old version doesn't seem
to work out of the box with rails 2.0 for me, I decided to test out
the latest version.

So, I'm looking at the scheduling, and trying to figure out the best
option for what I want to do.  What I have is a set of workers that
each poll the database occasionally.  I'd like to set it up so that
each of them can poll for work, do the work (however long that may
take), then pause for a "sleep time" and start over.  With the old
version of backgroundrb, I was never able to get any of the scheduling
options to quite do what I wanted to do, so I just ran without
scheduling. I manually started all my workers by calling
MiddleMan.new_worker in a script, passing in the "sleep time", and
then implemented each worker something like this:

  def do_work(args)
    @args = args
    @sleep_time = @args[:sleep_time]
    logger.info "CampaignStarter #{jobkey} started"
      # do the actual work in another method
      sleep @sleep_time

That seemed to work pretty well for the most part.

So now, looking at the current version.  I'm guessing that it's
probably not OK for me to use create() the way I was using do_work()
in the past;  Presumably create() is supposed to return at some point.
 Besides which, one of my workers needs to have multiple instances, so
I have to pass in a job_key somewhere.  I'm guessing that I should
call MiddleMan.new_worker(), telling it to run my main_work() method
with some scheduling option, but I'm not sure which scheduling option
to use.  I don't want to schedule it to run every 10 seconds, since
each call to main_work could take anything up to several minutes, and
I don't want the invocations piling up. The docs also seem to suggest
that I could do things my old way by calling MiddleMan.ask_work() and
letting it run forever, but it's not clear whether I can pass in a
job_key there.  I'd love any suggestions here...

Next, is there any way from inside a worker to see what its job_key
is?  With the old version I've been using the jobkey as a way to split
up some of the work requests, so each instance of my worker class
needs to know its own key in order to find what work is assigned to

Finally, it's not at all clear to me how the current version handles
multiple instances and threads.  For example, if I call
MiddleMan.new_worker(), does it actually create a new instance of my
worker class (as the old version did), and if so, is that instance in
a new thread of its own?  How about MiddleMan.ask_work() and

// jack
// http://www.nuthole.com

More information about the Backgroundrb-devel mailing list