[Backgroundrb-devel] Backgroundrb alternative idea
jonathan.wallace at gmail.com
Fri Nov 9 10:41:04 EST 2007
That's exactly the use case we determined we had when we decided to
stop using backgroundrb at my day job. A database queue served our
purposes quite well. A minor adjustment is that we cron the ruby task
running script to run periodically. The task is only submitted to the
queue by the user and not necessarily spawned immediately as you
suggest below. This should insure that the hardware resources aren't
overwhelmed by a click happy user as only one job would be processed
at a time from the queue. This also allows us to scale up queue
processing servers simply and easily.
However, in another project I'm involved in, backgroundrb is a perfect
fit because it is necessary for rails to provide the user with status
information of the long running task continually as it is running.
Though this could be accomplished using the database as an interim
status store similar to what you mention below, it is more responsive
to use backgroundrb and the results worker in our case. Since the
workers don't exist any longer than necessary, we have yet to run into
issues of stability like those reported to this list.
On Nov 9, 2007 10:08 AM, Reynard <reynard.list at gmail.com> wrote:
> I was just thinking if this simple idea would serve to replace backgroundrb:
> What if the worker is replaced with just a ruby script (can be
> anything actually: php, perl, etc)
> Rails application can just spawn new process by calling this worker
> script (passing data, and possibly uniq id)
> The worker script then store the result in database keyed by the uniq
> id (which is accessible by the Rails app), So the Rails app can check
> on the result by querying the database.
> Isn't that exactly what backgroundrb does?
> I would love to get comments / suggestions.
> - reynard
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
More information about the Backgroundrb-devel