Project

General

Profile

Actions

Bug #61670

closed

cleared cache_classes causes fatal error

Added by Philipp Wrann over 9 years ago. Updated about 9 years ago.

Status:
Rejected
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
Start date:
2014-09-17
Due date:
% Done:

0%

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

Description

When configuring the cache_classes to apc backend it may happen (apache reload for example) that the cache gets flushed, thus the cached code will not work anymore, fatals are thrown from bootstrap.

A on-the-fly class cache is not possible, i am aware of that (performance)
An additional check in the autoload function would also be a performance loss

But it might be a solution to ensure those caches are stored in the same backend.
So if you make the cache_classes cache implement the PhpCapeable Interface it would effectively make those caches to be stored in typo3temp/Cache/Code

That would make the bootstrap more robust.

Additionally you should ensure all Classes used in the bootstrap are accessible via convention, so event if the cache_classes is gone the bootstrap does not throw a fatal error. If i remove all t3lib_div from my localconf files (some older extension) there is still a fatal because of some logger from the core, that is not accessible via TYPO3 Naming Convention.

Fatal error: Interface 'Psr\Log\LoggerInterface' not found in .../typo3_src/typo3/sysext/core/Classes/Log/Logger.php on line 24

Alternatively you could also check the cache_classes cache very early in the bootstrap, if its empty recreate it...


Files

apc.png (41.7 KB) apc.png APC stats after one day of operating Philipp Wrann, 2014-10-16 09:39

Related issues 1 (0 open1 closed)

Is duplicate of TYPO3 Core - Bug #60760: Race condition during system cache flushClosedAlexander Opitz2014-08-04

Actions
Actions

Also available in: Atom PDF