Details
-
New Feature
-
Status: Closed
-
Minor
-
Resolution: Won't Do
-
2.4.9, 2.5.5, 2.6.2, 2.7
-
None
-
MOODLE_24_STABLE, MOODLE_25_STABLE, MOODLE_26_STABLE, MOODLE_27_STABLE
Description
While working on MDLSITE-2912 (new CI server), it was detected that currently recommended settings for opcache were leading to unit test failures because execution were using the "old" MUC's config.php all the time, not being able to pick the new versions generated by the tests.
Only setting "opcache.revalidate_freq=0" (aka, force mtime/hash verification on every use), helped to get the tests passing. Also, it would be possible to blacklist that file, preventing it to be caching ever.
This issue is about consider what happens with current recommended opcache settings via web. We have multiple "dynamic" .php files (MUC's config.php, lang files...) that could be affected by this issue. And setting "opcache.revalidate_freq=0" really kills one of the benefits of the cache.
Not sure if we are already cleaning opcache when these files are modified, note we added opcache specific code in MDL-40415, and there is a backport request about that too @ MDL-40554.
So possible situations are:
1) opcache specific code is already handling those .php file properly. nothing to do (just backport the issue above). I don't think this is the case, because, as, said, unit tests were failing in all branches because of this.
2) we are not controlling those files, and we need to do so, by any of:
- from moodle, reset caches on
modificationload of those files or upgrade... (required on load to support multiple opcaches that can't talk) - from moodle move from .php files to .xml or .json to escape from opcache.
- from moodle, blacklist those files, so we keep them out from opcache.
Ciao
PS: Example of failed unit test: link