[Backgroundrb-devel] best approach to managing workers and getting status

Jack Nutting jnutting at gmail.com
Wed Jun 25 03:32:56 EDT 2008

On Tue, Jun 24, 2008 at 7:26 PM, Frank Schwach <f.schwach at uea.ac.uk> wrote:
> Jack,
> I just found your interesting post in the archive and I would like to
> come back to this. I need to implement something like this:
> I have some very long running tasks (several hours) that should run on a
> remote machine and talk to the database on the Rails server. I need to
> keep track of jobs including those that have been run in the past, so a
> table for background jobs with their status as you describe would be the
> best solution for me.
> I am just wondering whether backgroundrb wouldn't be a bit of an
> overkill in the scenario you describe? In the new "Advanced Rails
> Recipes" from the Pragmatic Programmers Bookshelf there is a recipe
> using a simple daemonized ruby process that polls the database for
> pending jobs and uses acts_as_state_machine to set the state of the jobs
> (there is also a nice BackgrounDRb recipe in the book by the way).
> I am just wondering if the daemonized process isn't easier to handle in
> this case since you don't integrate your app with backgroundrb very
> tightly anyway?
> I would be grateful for any suggestions because there seem to be lots of
> possible solutions for this problem and some more or less well
> documented plugins and I haven't used any of them before. I need a
> simple and robust method that doesn't have too many dependencies and
> doesn't require too much maintenance because I want to make the finished
> app available for others to install on their local systems.

This is an interesting question, Frank.  My usage of backgroundrb is
somewhat of an edge case, and most of what I'm doing with it could
definitely be done with a simpler system.  I initially chose
backgroundrb for my project because it seemed to make the most sense
at the time (for what I *thought* I needed; actual needs changed with
further exploration of the problem space), and I was enough of a ruby
newbie that it felt comfortable for me to have a packaged solution
that (mostly) "just worked".  If I were starting from scratch today, I
might make a different decision.

However, it's not only inertia that keeps me using backgroundrb.  For
one thing, backgroundrb does provide some handy things--centralized
logging, IPC for storing runtime status info about my processes,
etc--that would take some time for me to implement if I were rolling
my own solutions with a daemonized script, and from my perspective
that would be wasted time, since I have those things working today
thanks to backgroundrb.  Another reason for me to keep it is that I
have a few spots in my system where I'm considering using some of
backgroundrb's other key features, like launching a short-lived
process to handle something in response to some action happening in
the main application

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

More information about the Backgroundrb-devel mailing list