[wp-trac] Re: [WordPress Trac] #8923: cron timeout is too short
WordPress Trac
wp-trac at lists.automattic.com
Fri Jan 23 00:45:48 GMT 2009
#8923: cron timeout is too short
--------------------------+-------------------------------------------------
Reporter: hailin | Owner: anonymous
Type: defect (bug) | Status: new
Priority: normal | Milestone: 2.8
Component: General | Version:
Severity: normal | Resolution:
Keywords: |
--------------------------+-------------------------------------------------
Comment (by hailin):
In the old code, where we used
fsockopen( $parts['host'], $_SERVER['SERVER_PORT'], $errno, $errstr, 0.01)
fputs( $argyle, "GET {$parts['path']}?check=" . wp_hash('187425'). ...)
0.01 only controls the the fsocketopen TCP handshake phase, it was saying
"the timeout for 3-way TCP handshake is only 0.01 sec", which is enough
since the host is local. Then we shovel GET into the pipe, and return.
All good.
The new code changed the semantics:
wp_remote_post($cron_url, array('timeout' => 0.01, 'blocking' => false));
Here the timeout is application layer timeout, meaning "If HTTP doesn't
get anything back in 0.01 sec, let's close the connection". When there are
many cron jobs in the queue, it's going to take longer time to fire them
up. And after 0.01 sec, the client closes the connection, either by
sending RST, or other means. This interrupts cron jobs despite we have
ignore_user_abort(true); at the beginning of wp-cron.php
So if we want to retain the "close without waiting" intent, it appears
only the old code achieves it. Otherwise, if we stick to wp_remote_post,
0.01 is going to cause issues.
--
Ticket URL: <http://trac.wordpress.org/ticket/8923#comment:4>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list