Are there any plans to support distributed jobs?
For example, when jobs grows too big to be accomplished between the cron
intervals.
I have been thinking of something like, acts_as_queue or
acts_as_queue_job.
Something to allow multiple threads and/or separate physical servers to
check out jobs for processing, without stomping on each other.
Using servers as an example:
Server 1 checks out a batch of jobs, processes the jobs and clears them
from the queue as they are finished.
Server 2 grabs the next batch, and so on.
Is Server 1 fails, the next machine grabs the unfinished jobs based on a
maximum checkout time value set during check out.
If a server exceeds the maximum checkout time value during processing,
it drops the remaining jobs and grabs a new batch.
Certainly there are many nuances I am missing. But this is my first pass
at a solution.
Any comments or code would be greatly appreciated. 
On 2/14/06, Lon B. [email protected] wrote:
If a server exceeds the maximum checkout time value during processing,
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
I currently don’t have any plans to support distributed jobs, because
my current apps don’t require it. RailsCron currently is
multithreaded.
If I was going to do simple distributed jobs, I would put:
return unless ENV[“HOSTNAME”] == “specific_server”
at the top of each action to let each server run a subset of the task
list. If you wanted multiple servers to run the same action on a
queue, then it isn’t too bad to implement that queue with an exclusive
checkout flag. This type of thing is separate logic from the idea of
RailsCron, and is suitable for the type of acts_as_queue plugin you
are talking about. I do something similar for sending bulk email, but
haven’t been able to extract a generalized plugin from it.
–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261
very very useful plugin.
But if someone is using migration, your plugin is not useable. Instead
of generating a tabel for the cronjob, it would be better to generate a
migration-script.
This is now a standard in rails.
Hussein M.
On 2/14/06, Hussein M. [email protected] wrote:
Posted via http://www.ruby-forum.com/.
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
A migration would be better, but this works fine, and doesn’t
interfere with your migrations. Maybe in the future.
–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261
On 1/25/06, Kyle M. [email protected] wrote:
–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261
I just tagged 0.2.1 which fixes several minor issues, and adds the
:concurrent option suggested by the list.
background :method, :concurrent => true
STUFF HAS BEEN REMOVED!!
- The overlap option has been superceded by concurrent.
- RailsCron DOES NOT start automatically. Please use the rake tasks.
This was a problematic feature, but if you can code it without side
efffects, the patch is welcome.
–
Kyle M.
Chief Technologist
E Factor Media // FN Interactive
[email protected]
1-866-263-3261