[wp-hackers] Dealing with WP cron's raciness
david at wordshell.net
Fri Sep 20 12:46:56 UTC 2013
Dion Hulse (dd32) wrote:
> I just wanted to point out, that doing this bypasses the major component of
> WP Cron which attempts to allow things to only run once.. doing so you'll
> almost be guaranteed to have duplicate events fired.
> When WordPress fires off the cron, it creates a locking transient (which
> should be pretty reliable when using an external object cache, not awesome,
> but still pretty good, when not) which is based on microtime(true) which
> includes microseconds: 1379596515.2753798961639404296875
> The request is then made via
> wp-cron.php?doing_wp_cron=1379596515.2753798961639404296875. If the GET arg
> doesn't match exactly what's in the transient, that request doesn't perform
> any operations.
Thanks for the feedback... I mentioned before a couple of things:
1) My motivation is to torture-test the worst-case scenarios, because
they are what generate support requests. A significant number (i.e.
significant enough to generate a flow of support requests, once you have
5,000 new installs a week) of hosting companies disable this mechanism
(in part, through disabling loopback HTTP connections), and instruct
their users to call wp-cron.php directly (via a scheduler in their
control panel). (I know that's "non-optimal". I know about
ALTERNATE_WP_CRON - as I say, I'm trying to deal with what users are
doing and likely to keep on doing, not what they ought to do).
2) I said before to Otto that from my reading of the code in
wp-cron.php, there's also an attempt to apply the same locking mechanism
you describe above in there. The only difference is that the loopback
HTTP introduces a slightly random timing delay, which fortuitously gives
the time delay needed for the locking mechanism to work - i.e. the
effect is a side-effect of the method,rather than procured directly by
it. Am I reading that wrong?
Paul Menard wrote:
> I actually have reasons in the past to rely on the multi-instance cron processing for some sampling plugins I wrote. Each instance needed to be independent. I don't want WP to be the traffic cop.
If you need to *rely* upon an action running twice, then surely you
should just schedule two actions? Note that I wasn't suggesting locking
at the *individual action* level but at the *cron queue processor* level.
WordShell - WordPress fast from the CLI - www.wordshell.net
More information about the wp-hackers