[wp-trac] [WordPress Trac] #15148: Cron Storage Abstraction

[WordPress Trac]

#15148: Cron Storage Abstraction
-------------------------+-----------------------------
 Reporter:  ryan         |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Cron         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+-----------------------------

Comment (by mintindeed):

 I've attached an updated version of Ryan's patch.  I've tested it locally
 and fixed a few minor bugs, but haven't tested it in production yet.

 I'm also attaching a cron.php drop-in that would use a separate cron job
 table.  This drop-in won't handle concurrent wp cron processes any better
 than the current wp cron, but it will handle prevention of duplicate jobs
 and prevent race conditions that cause jobs to get lost.  Concurrent
 instances of wp cron could be minimized by updating executing jobs to the
 "processing" state and checking the job state prior to executing.  They
 could be completely eliminated by spawning 1 cron process to handle each
 queued task, but I didn't want to get too ambitious without feedback.

 Some of the modifications include:

 * Private methods are handled entirely within the cron store class, cron
 API no longer uses private methods but instead passes arguments to the
 cron store class

 * Changed WP API to pass functions directly to the cron store class.  The
 cron store can figure out how it wants to handle those params.

 * Ryan's previous patch removed the procedural versions of
 _get_cron_array, _set_cron_array and _upgrade_cron_array, this patch takes
 the next step and actually labels them as protected methods.  Not having a
 publically-accessible version of these methods may break some plugins that
 used them in spite of being labelled with @access private.  If that's the
 case, may need to make the methods public and create a public procedural
 function that also invokes doing_it_wrong and _deprecated.

 * I wonder if it's cheaper for *_Cron_Store->get_event() to first check if
 the event exists, if not then immediately query the event from the
 database rather than looping through the current cron array?

 * Can't bail out of *_Cron_Store->get_event() early if _cron_array is
 empty, because there may be events stored in the database.  Don't want to
 query all pending events because of large job queues, e.g. Disqus on sites
 with a lot of comments.

 * If using the PMC_Cron_Store class, wp-cron.php could be improved by
 updating in-progress jobs to "processing" status.  Then it would be
 possible to go back and see what jobs failed/never completed, and
 potentially have an automated process that would retry them and/or alert
 the admin that the jobs never completed.  It also paves the way for having
 wp cron spawn 1 process to handle each pending job it tries to process,
 rather than trying to procedurally complete jobs.  This would
 theoretically negate the need for the "doing cron" transient.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/15148#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software