[wp-trac] [WordPress Trac] #25773: can not update option in wp 3.7 and hanging in wp_clear_scheduled_hook()

[WordPress Trac]

#25773: can not update option in wp 3.7 and hanging in wp_clear_scheduled_hook()
--------------------------+--------------------
 Reporter:  dimagsv       |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  3.7.2
Component:  Cache         |     Version:  3.7.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------
Changes (by kurtpayne):

 * cc: kurtpayne (added)


Comment:

 I cannot reproduce this using the instructions given.  I assume, based on
 the description, that there is an object cache present.

 Replying to [comment:4 dd32]:
 > So we've got 2 bugs here, based around the same thing,
 > 1. If `wp_clear_scheduled_hook()` has been run in another thread,
 `wp_clear_scheduled_hook()` will endlessly loop in the current thread,
 because:

 Is there a reason that we can't just make crons uncacheable?  Something
 like this (don't cringe)

 {{{
 add_filter( 'pre_option_crons', function() {
     wp_cache_delete( 'cron', 'options' );
     return false;
 }, -PHP_INT_MAX );
 }}}

 > 2. `update_option()` may now fail in "high-traffic" situations where an
 option is being updated my multiple threads to the same value.

 Definitely can replicate this.  If there is a multiple cache situation
 (like fastcgi + APC) then caches will get out of sync with each other and
 database very easily.

 > A unit test might be hard for this scenario, but should be able to
 replicate it by modifying the DB directly..

 Yep.  Let's focus on the cron issue, then move on to the bigger caching
 issue in another ticket.  If you can help me reproduce this, I can start
 writing some tests around it.

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