Bug #67366: PHP Errors after clearing cache in BE - Core - TYPO3 Forge

Core Indexed Search Linkvalidator Release Cycles Team Resources Workspaces & Versioning TYPO3 CMS Usability Team Community Extensions Distributions Feature-Requests TYPO3 6.2 Projects (+)(Archived Projects)

Bug #67366

PHP Errors after clearing cache in BE

Added by Alexander Ließmann about 1 month ago. Updated 15 days ago.

Status:

New

Start date:

2015-06-09

Priority:

Must have

Due date:

Assigned To:

% Done:

Category:

Caching

Spent time:

Target version:

TYPO3 Version:

6.2

Is Regression:

PHP Version:

5.6

Sprint Focus:

Complexity:

hard

Description

Since we updated some of our customer sites to TYPO3 6.2, we saw some PHP errors in FE like this one:

Fatal error: Class 'tx_igldapssoauth_config' not found in /var/www/typo3conf/ext/ig_ldap_sso_auth/Configuration/TCA/Config.php on line 172

or this:

Fatal error: Class 'tx_realurl_apiwrapper'  not found in /var/www/typo3conf/ext/realurl/class.tx_realurl.php on line 177

There were some other errors with other class names. The problem seems to target a random class. It appears in TYPO3 BE and FE after clearing the cache. But not always, and this makes it strange for me.

I was able to provoke the behavior with something i found in the comments of a existing bug report:

Open page in FE
rm -rf typo3temp/Cache/Data/cache_classes/
Reload page in FE

If i have a look in typo3temp/Cache/Data/cache_classes/ now, there are only few files in it. The class, which is named by the error message, is listed as a 0 Byte file.

I found Bug #55099 and i thought this could be related.

Related issues

History

#1 Updated by Markus Klein about 1 month ago

Now that I read this here, I dimly remember having seen such an issue on a 6.2 instance as well. I thought of a realurl bug and moved to the version of helhum.

I'll install the original realurl again and will re-test.

#2 Updated by Markus Klein about 1 month ago

Category set to Caching
Status changed from New to Accepted
Assigned To set to Markus Klein
Target version set to 6.2.13
Sprint Focus set to Stabilization Sprint

#3 Updated by Markus Klein about 1 month ago

Status changed from Accepted to Needs Feedback
Assigned To deleted (~~Markus Klein~~)
Target version deleted (~~6.2.13~~)
Sprint Focus deleted (~~Stabilization Sprint~~)

Even though I could reproduce this on one of our sites, I'm failing to reproduce it again after having played around.

I did:

upgrade realurl from 1.12.8 to 1.13.3 via extension manager

It did not help to

clear system caches
clear general caches
hard-remove typo3temp/Cache/*

the error in FE persisted:

Fatal error: Class 'tx_realurl_apiwrapper'  not found in ....typo3conf/ext/realurl/class.tx_realurl.php on line 177

I made an intermediate upgrade to 6.2.13-dev and cleared typo3temp/Cache/* again and all of a sudden it worked.
I tried to reproduce by downgrading to 6.2.12 again, resetting realurl back to 1.12.8, clear all caches and re-did the update to 1.13.3 => still working

I did not clear the OPcode cache (which I never had to), so maybe this is related to this cache somehow.
(I tested on PHP 5.5)

Are you using the opcode cache of PHP? If so please try clearing it manually via Install Tool.

#4 Updated by Alexander Ließmann about 1 month ago

Currently we do not use an OPcode cache, so there should not be the Problem. Our TYPO3 Version is 6.2.12 and the realurl version is 1.13.3.

I found out how to reproduce the two errors mentioned in my posting above. We use the extension igldapssoauth for backend login. So this error is raised in the following cases:

Backend login attempt if typo3temp/Cache/Data/cache_classes is empty
Backend login refresh with Ajax if typo3temp/Cache/Data/cache_classes is empty
Call on "typo3/cli_dispatch.phpsh extbase something" if typo3temp/Cache/Data/cache_classes is empty

The realurl error is shown on a FE call only.

I have seen a third error mentioning a classname of one of our own extensions, but until now i do not know how to reproduce this one. It is used in a long running process called by crontab. Perhaps it occurs when the process is running and the folder typo3temp/Cache/Data/cache_classes is cleared in the meanwhile...

#5 Updated by Markus Klein about 1 month ago

I was told this issue should be resolved in 6.2.13, which will be released in the next few hours. Please test again with .13 then.

This must have been some issue in the class loader as I could verify the empty cache files. As I said, I'm not able to reproduce again and I'm sure I had no concurrent requests running.

#6 Updated by Kerstin Gerull about 1 month ago

Hi,

I am having nearly the same problem. I am not completely sure if it is exactly the same.

When you have too much traffic on your page the cache is not cleared completely before new cache entries arrive.
That is why I get the following error:
"PHP Fatal error: Class 'Tx_Solr_PluginCommand' not found in <path>/typo3temp/Cache/Code/cache_core/ext_localconf_97bba9aa9ddf78aa54d1ba36d6ec429832fc4c76.php"
But this is just an example.

Like Alexander Ließmann initially stated, this error message seams to be random, because the error can occure on every cached class. And if you test that at midnight (with nearly no traffic) everything works fine.

This is the test I can reproduce the error.

1. Use wget to read the hole page recursivly (to make traffic)
- I did this on our testing environment, because the live page has enough traffic to allways have the error
2. Clear the Cache in the Install Tool (TYPO3 6.2.9 and 6.2.13)
- And you get a white page with a 'random' error message.

Could someone else reproduce this problem on TYPO3 Version 6.2.13?

Greetings Kerstin

#7 Updated by Markus Klein about 1 month ago

Status changed from Needs Feedback to New

Reading your text brings another idea to my mind. I guess the caches are not locked before being cleared, therefore those concurrency issues occur, which are especially bad for the class loader cache.

Will be hard to fix that, but lets see.