fwiw Katello uses delayed_job for background jobs. Originally we thought of using Resque, but in the end decided against, in part because of its dependency on Redis.
Cheers, -d
On 11-12-01 9:29 AM, Francesco Vollero wrote:
On Thu, Dec 01, 2011 at 01:41:51PM +0100, Tomas Hrcka wrote:
Hi all,
the time has come, and we need to somehow implement background jobs. I am curently working on task which involve long run operations on provider side(ie. stop and delete). So I can make the UI not responding for 2-4 mins, but that is not what we want.
Question is what will we use for performing background jobs. On ruby-toolbox.com [1] is overview of ruby projects for background jobs. Or we can implement our own solution.
Well, if I may spend my two cents here, reinventing the wheel is just unuseful at this stage and 75% of the time we gonna have more problems than benefits.
Said that, the top-notch solution depend on what we want to achieve for our project.
To have an base idea, worth to be readed carefully this link: https://github.com/blog/542-introducing-resque since they make an analysis on the solutions they used before writing Resque.
Resque: It's been created and currently used by Github for their background processes to substitute Delayed job Requirements:
- Redis server (already in fedora)
Video demo for Resque in Rails: http://railscasts.com/episodes/271-resque
Delayed Job: It's a quite "stable" solution, that is designed to have is natural role in a Rails app.
Video demo for dejayed job in Rails: http://railscasts.com/episodes/171-delayed-job
Beanstalkd: Fast as hell (from my point of view) simple work queue, that ship with two different gems: stalker and beanstalk rb
Video demo for Beanstalkd in Rails: http://railscasts.com/episodes/243-beanstalkd-and-stalker
Requirements:
- beanstalkd server (already packaged in fedora)
Pitfalls:
- Stalker and beanstalk gems are not shipped with fedora, so we need to package for ourself.
My Solution: Old and bugged with massive usage of unix pipes ^_^ does not outperform at all, i think neither perform :)
Cheers, Francesco Vollero