Drupal 8's service container cache does no checking for a stale container.
if it exists, and the mtime-hash matching is ok, it is loaded.
thus, any Drupal event that should lead to a new container must take care to remove the old one, so a new one will be built.
for a multiple webhead site, this requires a) that we put the cached php on a shared disk, or b) that we make sure to provide a custom container loader implementation that checks a central location to determine if the locally cached container is stale.
a) is scary for a lot of reasons, so this issue is about making b) work.
why do this in core and not contrib? because this is a regression from D7, and we don't want to force D8 users to install contrib modules just to have a sane multi-webhead site.
this patch provides Drupal\Core\PhpStorage\CoordinatedMTimeProtectedFileStorage, which does not run by default. to enable it, add this to settings.php:
<?php
$settings['php_storage']['service_container'] = array(
'class'=> 'Drupal\Core\PhpStorage\CoordinatedMTimeProtectedFileStorage',
);
?>CoordinatedMTimeProtectedFileStorage extends MTimeProtectedFileStorage and does two things:
- overrides MTimeProtectedFileStorage::getFullPath() to incorporate a counter, which is fetched from a global store
- overrides MTimeProtectedFileStorage::deleteAll() to increment the counter