Apc file exists cache

[e0ipso]

Allow flushing the file_exists APC caches (and add static cache).

This will also add a test on that feature.

[fluxsauce]

Hi Mateu, this looks great. However, since Pantheon relies on this repository, I'd like to get some more feedback from them before giving it a .

Paging @joshkoenig @davidstrauss @greg-1-anderson (not 100% sure who the point person should be)

[davidstrauss]

Flushing the cache for file existence should happen only after the deletions. Otherwise, it creates a race condition where the cache gets repopulated in a concurrent request with files that will end up deleted.

[e0ipso]

Good catch. I'll move the flushing right after:

file_scan_directory('public://css', '/.*/', array('callback' => 'drupal_delete_file_if_stale'));

[e0ipso]

@davidstrauss please re-review.

[deviantintegral]

@mateu-aguilo-bosch do we need a test case that simulates an expired APC cache item by calling apc_delete(), and then clearing caches? I don't see how the simpletest covers this issue (pasted from another ticket) - but it does look to be fixed in the actual code. Or does your test already fail if we run it against master?

On a Drupal cache clear, CSS and JS that have not been modified in 30 days are removed (configurable, but I don't think we've changed this). The file_exist calls are cached for 24 hours. I think the issue is if:

1. An asset is still valid, but hasn't been changed in 29 days.
2. The cache is expired in APC, and the file_exists call gets cached sometime in the last day of validity.
3. We do a cache clear after the file is 30 days old, but before the stat call has been expired in APC.
4. Worst case, this could lead to a broken asset for just shy of 24 hours. We could only fix it by restarting php-fpm entirely.