Bug #97731
open
DependencyInjectionContainer issues with shared storage on High Available setup
0%
Description
Hi There,
For a few customers we run TYPO3 on a High Available setup with multiple webservers and a single database.
All the caches and static contents (fileadmin, uploads) are stored on a network share (NFS) that all webservers can access.
Some requests will cause the following 500 error:
FastCGI sent in stderr: "PHP message: PHP Fatal error: require_once(): Failed opening required '/mnt/nfs/web/myuser/shared/var/cache/code/di/DependencyInjectionContainer_5cbe220783b1147afc206ff59cc1318dad117973.php' (include_path='.:/usr/share/php') in /data/home/myuser/sites/myuser/builds/latest/public/typo3/sysext/core/Classes/Cache/Backend/SimpleFileBackend.php on line 362
We already store almost all caches in Redis, but somehow the "DependencyInjectionContainer" caches cannot be stored in Redis.
We have these issues on multiple different environments.
Updated by Andreas Kiessling almost 2 years ago
Hi Jeroen,
did you find any solution for this? From time to time i get this error in multiserver deployments with a shared var directory for a v11 instance.
I could not yet move the var dir to the instances themselves, this caused other problems :/ Any hint on how to solve this would be very welcome!
Updated by Andreas Kiessling almost 2 years ago
In v11 the line that causes the error looks like this:
return file_exists($pathAndFilename) ? require_once $pathAndFilename : false;
I suspect that file_exists returns a result from the nfs cache, while require_once actually tries to read it and then fails. There may be different ways to tackle this:
a) tune your nfs settings to disable / reduce attribute caching which will very likely hurt performance
b) patch the ContainerBackend (which inherits from SimpleFileBackend) and flush the stat cache before the require_once / file_exists (or maybe mute the error, check if the class that is supposed to be in the require_once file actually exists, if not return false?)
c) disable sharing the var/cache dir
I went with option c, hope that it all works out. Flushing the system cache will not work afterwards!
Updated by Benni Mack over 1 year ago
- Status changed from New to Needs Feedback
with v11 one can warm up the caches (core + DI) during deployment. Best practice would be then to ship the DI cache with the artifact?
Updated by Sybille Peters about 1 year ago
- Related to Bug #100123: Regular exceptions due to dependency injection (di) cache added