Old content served by Memcached after manual cache clear

I'm unable to duplicate. How do you have memcache configured?

I've the same problem

my conf:

$conf['cache_inc'] = './sites/all/modules/authcache/memcache.inc';

$conf['memcache_servers'] = array( 'localhost:11210' => 'default',
                                   'localhost:11211' => 'block',
                                   'localhost:11212' => 'content',
                                   'localhost:11213' => 'filter',
                                   'localhost:11214' => 'menu',
                                   'localhost:11215' => 'page',
                                   'localhost:11216' => 'views',
                                   'localhost:11217' => 'views_data');
                                    
$conf['memcache_bins'] = array('cache' 					  => 'default',
                               'cache_block' 		  => 'block',
                               'cache_content' 	  => 'content',
                               'cache_filter' 		=> 'filter',
                               'cache_menu' 			=> 'menu',
                               'cache_page' 			=> 'page',
                               'cache_views' 		  => 'views',
                               'cache_views_data' => 'views_data');

$conf['memcache_key_prefix'] = 'test2';

What versions of memcache and the pecl extension are you using.
There's an issue with using the latest (1.4.3) version of memcache. See http://pecl.php.net/bugs/bug.php?id=16927

I have the same problem.

Using:
Memcache API module 6.x-1.4
Memcache PECL extension 2.2.5
Memcached 1.2.6, 1.2.8, 1.4.2, or 1.4.4

I have the same issue with all of the above versions of memcached. This is happening on a server with the most basic memcache config, as well as a config with multiple bins and session caching configured.

Please let me know if there's anything else I can do to help you get to the bottom of this.

edit: OK, this appears to be fixed in the latest dev snapshot. Maybe time for a new release?
edit: I was mistaken. Neither the 6.x-1.4 release nor the latest dev snapshot appear to be doing deletes properly.

I also have the problem with Memcached 1.3.3.

I uninstalled the latest Memcache API module and installed Memcache API 6.x-1.3. Now my cache is being flushed properly. Seems to work fine with memcached 1.2.6, 1.3.3, and 1.4.4. Seems like there's some kind of a bug in Memcache API 6.x-1.4 and above.

edit: With Memcache API 6.x-1.3 the cache seems to get invalidated every about every second request, so I really have no idea whether or not deletes are actually working.

OK, I got a little further on this. I had "Minimum cache lifetime" set in the page caching settings. If this is set, dmemcache_flush() will never be called. I don't know if this is the desired behavior, but this isn't the way Drupal normally works. When using standard Drupal caching even if I have a "Minimum cache lifetime" set, if I hit the "Clear cached data" button, the cache gets cleared. When I hit the "Clear cached data" button I am doing so because I want the cache cleared right now. I don't see why you wouldn't want it to work that way.

Anyway, to others who experience this issue, make sure your "Minimum cache lifetime" is set to "None".

I'm seeing this behavior regularly on my sites. Reading the code it's quite apparent what's happening.

Around line 136 in Memcache API 1.4:

    if (variable_get('cache_lifetime', 0)) {
      // Bunch of code...
    }
    else {
      dmemcache_flush($table);
    }

So it's exactly like adamo says. If you have any minimum cache lifetime set, dmemcache_flush() is never called. Instead there's a bunch of mumbo-jumbo about "simulating cache flushing for a single user". Of course this means that if the cache isn't cleared for anonymous users but only for administrators, they're going to get the same pages served up to them (with links to CSS files that don't exist) instead of freshly generated ones.

We were just talking about this at Sandcamp. Awesome find, quicksketch.'

Seems odd for an intentional bit of behavior, but if the workaround is just to set no minimum cache lifetime, so be it.

Setting the cache lifetime to 0 is a pretty bad idea generally, since it basically results in you setting caches but never actually using them, because they're already expired. It's the sort of thing that just doesn't make any sense.

To fix this we're using this hack that makes it so that the cache_lifetime is set to 0 just before the cache clearing routines are run, so that it properly flushes everything out and we can still have a lifetime.

We are having the same issue, with cached items not expiring as we would expect them to. Particularly with pages which contain links to aggregated css/js, which on clearing the cache are deleted, leaving the cached html linking to files which no longer exist.

UPDATED: We are having the same issue, with cached items not expiring as we would expect them to. Particularly with pages which contain links to aggregated css/js, which on clearing the cache are deleted, leaving the cached html linking to files which no longer exist.

I suggest the issue is with the logic in the cache_get if() statement:

<?php
if ($cache_lifetime && $cache->created && $cache_flush &&
    ($cache->created < $cache_flush) &&
    ((time() - $cache->created >= $cache_lifetime)) ||
    (is_array($cache_tables) && $cache_tables[$table] &&
    $cache_tables[$table] > $cache->created)) {
  // Cache item expired, return NULL.
  return 0;
}
?>

Changing to this:

<?php
if ($cache_lifetime && 
    $cache->created && 
    $cache->expire != CACHE_PERMANENT && 
    (
      ($cache->expire && $cache->expire < time()) ||
      ($cache_flush && $cache->created < $cache_flush) ||
      ($cache->expire == CACHE_TEMPORARY && (time() - $cache->created) >= $cache_lifetime) ||
      (is_array($cache_tables) && $cache_tables[$table] && $cache_tables[$table] > $cache->created))
    ) {
    
  // Cache item expired, return NULL.
  return 0;
}

?>

I am also seeing this issue, but the patch did not work. When Cron ran, the file was deleted (permissions on the dir appear fine) and now the Panels page is referencing a missing CSS file.

EDIT: I refreshed the page and the CSS is now there, though. Could be a fluke. If I can nail it down I'll post back.

This is the current patch we have in place, which appears to be working...although I wonder if it representing the temporary cache items the way it was intended.

@torgosPizza
You describe a different problem #717036: Remove css cache clearing from hook_flush_caches()

This error is very easy to fix after you spend some time to grok the whole picture. I think the whole problem originates from ambiguous terminology used by core. The word "flush" is abused: it can mean both "expire" and "delete" depending on context. This problem exists because Memcache API is using cache lifetime logic in "delete" context, while it should only do it in "expire" one. Note that drupal_flush_all_caches() explicitly deletes cache by passing an asterisk to cache_clear_all(), so indeed "mambo jumbo" mentioned by Nate above is not needed.

subscribe

subscribe, is it related with this issue #655538: cache_page not cleared via system_cron ?

Fix back ported from 7.x-1.x-dev:
http://drupal.org/cvs?commit=412692

Thanks very much for the work and the patches above. I have recently run across this issue, and found something interesting that I thought I should tell the developers about.

In my drupal install (6.19) the error condition described above is only triggered when we have "Optimize CSS files" turned on, and have "ini_set('session.name', 'somestring_PHPSESSID');" set in the settings.php. We're using 6.x-1.5 of the Memcached API module.

Our memcached settings in the settings.php file are very simple:

$conf = array(
        'memcache_servers' => array('localhost:11211' => 'default'),
        'cache_inc' => './sites/all/modules/memcache/memcache.inc',
);

I'm not sure why that's the case, but it may be helpful in diagnosis. Removing the ini_set for session.name and restarting apache to reload it seems to clear up the issue.

I got this error on a Drupal 6.20 installation with Memcache module 6.x-1.8 and memcached version 1.4.5. The implication was that pages with invalid aggregated js and css file paths were being delivered to anonymous users after a cache_clear_all was called by logged in user 1.

Why is it that a cache_flush_all timestamp variable can't be maintained to invalidate all cache stored before the time stored in the variable?

The following patch is a temporary work around - treat * as a cache_flush_table instead of as a wildcard. I do not know why * shouldn't be considered as a cache_flush_table in the first place.

There is no way that the original report here is the same bug as what you're seeing.

There are two patches that change this behaviour:
http://drupal.org/node/1103478#comment-4351462
Also, #1085626: Wildcard entries may go missing, leading to caches not being invalidated properly

Please test those, I'm closing this one again.

Should I open another ticket? The symptom is exactly the same and I can replicate this easily. I got the latest dev, applied patch from #1103478: Skip some wildcard fetches.

I am able to replicate this with consistency.

Logged in as administrator in one browser
Verified css path on home page for administrator
Opened site as anonymous user in another
Verified css path on home page for anonymous user
Cleared cache as administrator
Both css files listed above gets deleted from files folder
Administrator clears browser, logs out, cache and goes to site home page - css is gone. The path points to old and deleted aggregated css path.
Anonymous user refreshes home page - css is gone. The path points to old and deleted aggregated css path.

If minimum cache lifetime is set to 'none' then this issue would not occur.

You want #721400: Order JS files according to weight, don't change filenames for aggregated JS/CSS. That is not a memcache issue.

@catch - thanks for pointing me to the issue related to renaming of aggregated js and css files. I will probably go with that.

But I would still believe that there is an unexpected behavior with memcache because

a) Core drupal database based caching works with drupal_flush_all_caches for anonymous and logged in users
b) Switching to memcache changes this behavior by delivering content that was stored before an explicit drupal_flush_all_caches to anonymous users (possibly logged in users as well as I tested only with the current logged in user)
c) That this is a stale cache issue and not incorrectly generated filenames is evident because a memcached restart would start delivering pages with valid css names to anonymous users as well.

I do not want to reopen this issue if you don't agree to the above logic but I do believe that there is some case that is being missed in the logic used to serve cache. drupal_flush_all_caches should invalidate/delete all old cached items.

Re-opening this one last time so that you see my reasoning about the issue.

The issue with database compared to memcache is that core currently sets page cache items as CACHE_TEMPORARY. This means that not only cache flushes but just regular from runs wipe the page cache from the db. There is unfortunately no way for memcache to be able to tell the difference between a full cache flush by the adminstrator and the normal clears during sure operation. It tends on the side of better hit rates in that case. I have a core issue open to set a real expires value on the page cache, but this isn't done yet. Hope this helps to explain things. Again I'd consider this memcache working around deficiencies in the core cache api/implementation leading to slight changes in functionality, rather than a bug as such.

@catch - thanks for the explanation. Can you please point to the core issue as well so that this clarification is complete for this thread.

#891600: Page and block caches are cleared the same way on cron as on content change.

For those who are looking for a solution, the patch in http://drupal.org/node/721400#comment-2950544 will take care of the issue with missing css files corresponding to pages stored in cache_page