Bug #63135

Need a stopgap fix for SimpleFileBackend cache locking

Added by Gabe Blair almost 7 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
Caching
Target version:
Start date:
2014-01-24
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

This is a copy of the original reported issue (https://forge.typo3.org/issues/55294):

On sites with rather high load, we have witnessed a rare problem, where two request is apparently writing to the same cache file at the same time. This happens if the cache is cleared, and two requests both try to populate the cache_core cache, which is i SimpleFileBackend cache. 

In some cases the file might be a file that is only needed by an extensions, and pages using that will fail, in some cases the file might be one that is also used by the backend, which means the backend is effectively broken, and its not possible to clear cache (other that manually deleteing the typo3temp/Cache/Code directory).

The problem is much worse on a slow filesystem, and I believe that it is due to SimpleFileBackend nt using a filelock before writing the file.

The fix should be very easy. Simply either issue a flock directly in SimpelFileBackend, og use TYPO3 locking mechanism.

We are experiencing the same issue on a relatively high-traffic site using TYPO3 6.1. This is harsh when it happens, because it brings down the entire site with a PHP error, when a PHP cache file is partially or doubly written. This issue has proven quite difficult to reproduce for development/testing purposes, but it definitely is real.

The SimpleFileBackend uses file_put_contents() to create the temp file that eventually becomes (https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Classes/Cache/Backend/SimpleFileBackend.php#L238). However, file_put_contents() is not locking, by default (http://us.php.net/file_put_contents). Can anyone think of a downside to using the "LOCK_EX" flag in file_put_contents() to allow PHP to handle the locking? This effectively issues an flock() before writing, and removes it afterwards.

Obviously there is some activity at the moment around cache locking in general. But how about we at least use native PHP support for locking as a stopgap measure for SimpleFileBackend until a more holistic locking mechanism can be developed overall for caches (http://wiki.typo3.org/Blueprints/LockingForCaches)?


Related issues

Is duplicate of TYPO3 Core - Bug #55294: Under heavy load, two request can simultaneously write to same cache file - should use lockingClosedBenni Mack2014-01-24

Actions
#1

Updated by Gerrit Code Review almost 7 years ago

  • Status changed from New to Under Review

Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34459

#2

Updated by Gerrit Code Review almost 7 years ago

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34460

#3

Updated by Gerrit Code Review almost 7 years ago

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34461

#4

Updated by Alexander Opitz almost 7 years ago

Hi Gabe,

thanks for your contribution.
Please, at first only push patches for the master branch. If they are well, then they will be backported by the team.
And for the 6.1 branch, we may accept security patches, but it is out of maintenance. See http://typo3.org/fileadmin/t3org/images/FM-content/team-pages/core-development-team/TYPO3_Release_Agenda_LTS-2013-v2.pdf

Will take a look into the patch next days.

#5

Updated by Gerrit Code Review almost 7 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/34461

#6

Updated by Benni Mack over 6 years ago

  • Assignee set to Benni Mack
  • Target version changed from next-patchlevel to 7.3 (Packages)
#7

Updated by Benni Mack over 6 years ago

  • Status changed from Under Review to Resolved

Fixed with composer class loader in 6.2 and master

#8

Updated by Riccardo De Contardi almost 4 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF