[wp-hackers] memcached object cache breaking http head requests

[Wordpress Developer]

We aren't dealing with this particular issue, but I can assure you
you're not alone in object-caching troubles.

We think a 32-bit vs. 64-bit issue might be causing this for us:
http://mu.wordpress.org/forums/topic/12417?replies=10

On a 32-bit machine we're not getting admin pages to hang but we're
having all kinds of object caching issues: posts unpublishing, changed
passwords not updating -- bad stuff.

From: http://lists.automattic.com/pipermail/wp-hackers/2010-April/031341.html

xxx


Recap: memcached + WP = empty headers or 503 errors. Simply removing the
memcached enabled object-cache.php file or commenting out the places where
it's initialized solves the problem (though performance suffers).

I had wondered if changes in how the cache is initialized in 3.0/trunk would
affect this (the use of wp_cache_reset() instead of   wp_cache_init seemed
as though it might be significant), but I've tried the new code without any
improvement (I've also realized that wp_cache_reset() isn't implemented in
the most current version of the object cache (
http://plugins.trac.wordpress.org/browser/memcached/trunk/ ), so the overall
behavior really hasn't changed much).

I'm seeing this problem on three different hosts...is it truly possible that
nobody else in the WordPress community has experienced it before?

On Sat, Mar 20, 2010 at 10:16 AM, Casey Bisson <casey.bisson at
gmail.com <http://lists.automattic.com/mailman/listinfo/wp-hackers>>wrote:

>* This is an odd one.
*>*
*>* When running WordPress MU (tested in 2.8x and 2.9x) with the memcached
*>* object cache active, it refuses to respond to HTTP HEAD requests. The result
*>* of this is that head requests to check the mimetype of a linked file (as for
*>* setting the enclosure) or size (as the video framework plugin does) fail.
*>*
*>* curl -I http://url.path
*>*
*>*
*>* returns either an empty result, or (if fronted with varnish) a 503 error.
*>*
*>* telnet site.org 80
*>*
*>*
*>*
*>* HEAD /url.path HTTP/1.1
*>*
*>* host: site.org
*>*
*>*
*>* returns the same.
*>*
*>* Moving object-cache.php out of /wp-content or commenting out one line (
*>* $this->mc[$bucket]->addServer(...) ) solves the problem. Oddly, the problem
*>* occurs only when wp_cache_init() is called the second time in
*>* wp-settings.php (if I comment out that line, the problem disappears as well,
*>* even though the cache was initialized previously).
*>*
*>* The problem occurs with multiple revisions memcache object-cache.php,
*>* including the most recent, on multiple servers with different versions of
*>* memcached.
*>* http://plugins.trac.wordpress.org/browser/memcached/trunk/
*>*
*>* I have not yet had an opportunity to test this with non-MU versions of WP
*>* or with /trunk/ (where it appears that calls to wp_cache_init() have been
*>* replaced with wp_start_object_cache() ), so there's a good chance this is MU
*>* specific or fixed already, but in all my searching I haven't been able to
*>* find any mention of the problem.
*>*
*>* I'd love to know if others have experienced this problem or solved it.
*>*
*>* --Casey
*>*
*