-
Bug
-
Resolution: Fixed
-
Minor
-
4.1.3
There are two problems with cache locking (which has been around a while but not used much, and was implemented for modinfo and modified in 4.1), both related to acquire_lock function:
- The cachestore_redis and cachestore_file implementations of this function behave differently. cachestore_redis returns false immediately if the lock can't be obtained right now, whereas cachestore_file has a lock wait setting (60 seconds default) and will retry within that time limit and only return false if it still can't get it. (There is one other mechanism, the default one used if the store doesn't support locking, which also has a similar retry approach.)
- The acquire_lock function returns false if it doesn't acquire the lock, but the build_course_cache function ignores the return value and goes ahead to build the cache anyway. (Actually, other places that call this function do the same, it's not really obvious that it can return false...)
As you can see the second problem may be more serious but both probably need fixing
The actual consequence of this is that in a scenario with Redis cache, it is possible that requests which rebuild modinfo cache can result in errors about how the cache lock isn't acquired. (This happens when it was acquired, but because locking doesn't work, the system then lets somebody else acquire it before the first request gets around to actually using it to set the data.)
On our test server (thankfully, we are not live with 4.1 yet) we see this in the system error logs as occasional, sporadic occurrences of the 'Locking before writes is required for core/coursemodinfo' error message.
This patch currently makes the following changes:
- The cachestore_redis lock implementation is changed so that it retries the lock for a given 'wait' period (default 1 minute). Once acquired, locks also time out (default 10 minutes), in case a process crashes without releasing a lock.
- The code in modinfolib is changed to actually check that it acquired the lock, and if not, throw an exception.
- has a non-specific relationship to
-
MDL-77851 course_modinfo does not check whether a lock has been successfully acquired
-
- Open
-
-
MDL-78109 Cache: Remove harmful requirelockingwrite/requirelockingread options
-
- Closed
-
- has been marked as being related by
-
MDL-78154 Completely remove locking from MUC and reimplement requirelockingwrite
-
- Closed
-