[drupal-devel] [feature] Pass include and exclude parameters to cron.php for fine grained cron timing

[Robert Castelo]

Issue status update for http://drupal.org/node/19173

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     feature requests
 Priority:     normal
 Assigned to:  robertDouglass
 Reported by:  robertDouglass
 Updated by:   Robert Castelo
 Status:       patch

+1 from me.
I'll be needing something like this once my email newsletter is
released and starts hogging cron runs.


Robert Castelo



Previous comments:
------------------------------------------------------------------------

March 20, 2005 - 11:08 : robertDouglass

Attachment: http://drupal.org/files/issues/cronpatch.txt (1.99 KB)

Some sites need fine grained timing for cron runs. For example, a site
that relies heavily on moblogging, mailhandler or any other email based
function would want to connect with the email server pretty often, say
ever 2-5 minutes. On another site I'm working on we generate flat files
for all of a certain node type on a regular basis, though not every 2-5
minutes. Thus the need for cron tasks on different schedules. This
patch allows you to make a list of modules to either include or exclude
when running cron, so that several cron tasks for one site can be
defined. The default behavior in the absence of both parameters is to
run all, so the patch preserves backwards compatibility.
 * Examples:
 *
 * runs all hooks
 * http://mysite.com/cron.php
 *
 * runs all hooks except the search and aggregator modules
 * http://mysite.com/cron.php?exclude=search,aggregator
 *
 * runs only search, archive and aggregator modules
 * http://mysite.com/cron.php?includ=search,archive,aggregator


------------------------------------------------------------------------

March 23, 2005 - 22:23 : Dries

Isn't it possible to run all cron functions every 2-5 minutes?  The
impact of that should be minimal.


------------------------------------------------------------------------

March 23, 2005 - 22:33 : moshe weitzman

an alternative approach is to make a quick PHP page which simply calls
mailhandler_cron and any others that need to be called more frequently
than normal. then call that php page from cron every couple minutes ...
not so sure this complexity is worth having.


------------------------------------------------------------------------

March 24, 2005 - 08:32 : robertDouglass

Whether or not this "complexity" is needed depends a lot on what you
expect to do with cron. As soon as one starts aggregating not tens but
several hundred RSS feeds or more, it is impossible to run cron every 2
minutes. Yet if the site depends on mailhandler keeping user moblog
submissions current, 2 minutes is already about the maximum latency
time acceptable. Thus the need for crons on different schedules.
In terms of usage, writing 
  ?include=mailhandler,search,event 
isn't so complex. On the code level, splitting that list on comma and
looping over the resultant array also isn't really that complex. The
patch defaults to normal behavior for people who don't need the
feature, and I've seen more than one site that had to solve this
problem.


------------------------------------------------------------------------

March 24, 2005 - 11:48 : Robert Castelo

Could different cron runs be set to run different tasks based on a cron
ID number....
For instance, set up 3 separate cron to run every hour, each one calls
the cron.php page including a number variable which runs a certain set
of tasks.
An Admin control panel would list all cron tasks and allow
administrators to split them into separate cron runs based on the
number variable passed to the script when calling cron.php.


------------------------------------------------------------------------

March 24, 2005 - 12:24 : robertDouglass

Robert,
the id parameter is already a practical necessity for this patch if
cron_busy is to be effective. I'm open to suggestions as to how we
would track various cron tasks and whether they are busy.
First things first, though: does anyone except me need this?
I'm not going to program an admin-configurable cron mechanism unless
there is demand for it. Furthermore, such a system would really be
incomplete unless there were some actual mechanism for setting these
cron runs up from the admin interface as well. This wouldn't be such a
bad idea, I know a lot of people who still type /cron.php into their
browser every day or so to updated thier sites (yes I've mentioned
poormanscron). Anyway, first reactions to this patch have been cold, so
maybe nobody wants it.