[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