Background Jobs in conductor
Francesco Vollero
fvollero at redhat.com
Thu Dec 1 13:29:32 UTC 2011
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
More information about the aeolus-devel
mailing list