Page cache never expires if page_cache_without_database is enabled

We see same problem here, drupal 7.14, memcache 7.x-1.0.

We're having the same problem.

If you change
$conf['page_cache_without_database'] = TRUE;
to
$conf['page_cache_without_database'] = FALSE;

Then it works as expected.

But that will no doubt affect performance as Drupal does a bit more bootstrapping even if the page is cached.

I'm guessing it's because when it's set to TRUE, Drupal doesn't load the variables, and memcache is using a variable somewhere when grabbing cached pages?

(I believe the reason it doesn't flush the cache is because it would do this every time cron runs)

To confirm #3, when $conf['page_cache_without_database'] = FALSE; drupal bootstraps the variables, as can be seen here http://api.drupal.org/api/drupal/includes!bootstrap.inc/function/_drupal_bootstrap_page_cache/7

I think I'm seeing this exact same issue on our site. Pages cached for anonymous users won't expire. I tested #3 and it doesn't appear to work on my end.

The following sort of works for us ('sort-of' because we have other settings & are not sure if this is the real fix). Would be good to get confirmation if it helps others. Basically we found that drupal was not setting the correct expiry via memcache as it relied on the 'Expires' header in drupal_page_set_cache

Put this into a module:

/**
 * Implementation of hook_preprocess_page
 * Adds Expires header based on the configuration of Minimum Cache Lifetime
 */
function mymodule_preprocess_page(&$variables) {
  global $user;

  if ($user->uid == 0) {
    if (variable_get('cache_lifetime', 0)) {
      $expire = REQUEST_TIME + variable_get('cache_lifetime', 0);
      drupal_add_http_header('Expires', gmdate(DATE_RFC1123, $expire));
    }
  }
}

Flush all cache & memcache and try again.

Hello,

Here is how I understand this bug, or at least the impact of cache_page_without_database:

• Most content update will trigger cache_clear_all(); (e.g. from node_form_submit())
• Called in this way, this is equivalent to:
• _cache_get_object('cache_block')->clear(NULL, FALSE);
• _cache_get_object('cache_page')->clear(NULL, FALSE);
• MemCacheDrupal::clear() will simply store the current time into:
• its cache_content_flush attribute, for next calls to MemCacheDrupal::get() -- the Memcached module does not invalidate entries into Memcached, it simply instructs get() to return false for entries created before the last required flush
• the variable cache_content_flush_cache_page (or cache_block) is used to make this date persistent
  and here lies the problem: since it is stored as a standard Drupal variable (and potentially cached in another bin, by another cache class or even not cached at all), it is theoretically unreachable without connecting to the database and bootstrapping the variables, even though it is potentially still available within Memcached.

Still, I wonder whether some or all of the variables mentioned in MemCacheDrupal::reloadVariables() could be systematically stored into Memcached, without any dependency to Drupal variables. Another approach consists in trying to load variables from Memcached, and connecting to the database only if it fails...

P.S.: by the way, in the code quoted by #3, shouldn't it be $cache_bins instead of $cache_tables?

I am attaching a fluxogram of what happens during bootstrap, which means, the variables get loaded during phase 3
Also, attaching a DOC version with links to the actual code and another fluxogram of how memcache works.
ps: all of these are todo only with page cache, other areas of caching havent been covered

I've seen the same issue as well. When using `drush cc all`, the cache isn't cleared. It seems not just for page cache but all caches handled by memcache is not cleared.

@andyhu have a look at this http://drupal.org/node/1279654#comment-6473782

Maybe an integration with http://drupal.org/project/expire would help...

Will this work for d6?

Comment out:

  $conf['cache_backends'][] = 'sites/all/modules/contrib/apc/drupal_apc_cache.inc';
  $conf['cache_class_cache'] = 'DrupalAPCCache';
  $conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';

Hello,

I am facing a similar problem but I am not sure if the cause is cached variables. Let me explain the symptoms.

* Core - 7.22 Memcache - 7.x-1.0
* When a new article is added, it never appears in a views stream after the cache lifetime.
* I set it to 1 min but it takes much longer to appear unless the cache is explicitly cleared.
* Two particular bins (bootstrap and filter) are dangerously full (close to 99%) and there are 0 evictions from there.

It would be great if someone facing similar issues could post some suggestions.

Thank you,
Swati

Bumping to major as this affects everyone who uses memcached for page cache and has page_cache_without_database set to TRUE.

Duplicated; agreed it's a major bug. Assigning to myself to fix.

Please test the attached.

This adds a bit of extra overhead with this setting compared to not having it, but I can't think of another option except storing that information outside the variables system altogether - and that'd still be an extra round trip.

      if ($cached = cache_get('variables', 'cache_bootstrap')) {
+        $variables = $cached->data;
+        foreach ($conf as $name => $value) {
+          $variables[$name] = $value;
+        }
+        $conf = $variables;
+      }

Since we only care about a couple of variables here, what about just picking those out rather than the foreach() over all variables?

This extra loop only happens when page_cache_without_database is TRUE -- when it's FALSE, this loops still happens but in bootstrap.inc while bootstrapping variables.

I'd not expect this to have a measurable impact, except perhaps on a website with a massive $conf array... and IMO that's a user error anyways. Further, the variables we care about are not static (they depend on configuration), and figuring out on each bootstrap which variables are required is likely comparable overhead -- again, except in the case of an over-sized $conf array.

I suppose the thing to do here is to set up a load test and compare...

Yes, I do not see a performance problem with this loop either. It's the usual loop keeping $conf overrides and won't affect installations without the variable set.

Attached is an updated patch with variable namings that make more sense to me and some comments explaining whats going on. Then, I removed the manual call to _drupal_bootstrap_page_cache() - not sure why we'd need that?

Patch seems to do its job for me and offers the same performance as before, but with working cache clears.

Thanks, fix committed:
http://drupalcode.org/project/memcache.git/commit/a534d3d

I'd hoped for more confirmation from testers; I'll roll a Beta to make this easier.

If using APCCache for cache_class_cache_bootstrap (as per #14), this problem still persists when clearing caches with drush.

This is because drush can't clear the APC cache, as discussed here: https://www.drupal.org/node/1565716

Can work around this by commenting out this line in settings.php

$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';

Followup for Authcache: #2361001: Page cache never expires if authcache_builtin_cache_without_database is enabled