Sam,
I performed an analysis on background processing alternatives (see
below). I greatly recommend rolling out your own daemon for recurring
jobs, or using starling+workling for offloading jobs from your rails
app. Both alternatives are covered in excellent railscasts by Ryan
Bates.
Cheers, Sazima
BACKGROUND PROCESSES
-------------------------------------
http://wiki.rubyonrails.org/rails/pages/HowToRunBackgroundJobsInRails
== Asynchronous Tasks
Launched from Rails request/reponse cycle + optional Message Queueing
- Options
. ar_mailer (only for emails) => GOOD (only email)
. starling + workling => EXCELLENT
. Ap4r
. Spawn / background => SIMPLE
. ActiveMessaging
. BackgroundFu
. WorkerQueue
. Rake in Background => SIMPLE
(http://railscasts.com/episodes/127-rake-in-background)
== Recurring Jobs (cron-style)
Scheduled or permanently running in the background
- Options
. daemon_generator (rails_cron) => SIMPLE
http://railscasts.com/episodes/129-custom-daemon
. BackgrounDRb
. rufus-scheduler => GOOD
. Taskr
. UNIX Cron and Runner (simple, but consumes resources and you can't
controll well)
On Jan 13, 4:21 am, Sam Wilson <[email protected]> wrote:
> When your server does 1 Ruby operation a day without anyone having to
> visit the site to make it happen. Let's say the operation would be to
> create an automatic blog post on your blog site every 24 hours. This
> is an example what I am curious about if any RoR code can be run
> without users visiting. Also is this an advanced or beginner's topic?
>
> Thanks!
> Sam
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
