Hi, 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. Regards, - reynard
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. Jonathan On Nov 9, 2007 10:08 AM, Reynard <reynard.list at gmail.com> wrote:> Hi, > > 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. > > Regards, > - reynard > _______________________________________________ > Backgroundrb-devel mailing list > Backgroundrb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/backgroundrb-devel >-- Jonathan Wallace
Thanks for the advice on performance consideration, I guess I''ll just have to try it and test to make sure the perfomance will be ok. It''s good to know someone else has done it though, and this probably just a temporary solution until the new backgroundrb is released and stable :) Regards, - reynard On Nov 9, 2007 10:41 AM, Jonathan Wallace <jonathan.wallace at gmail.com> wrote:> 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. > > Jonathan >