I can't reproduce this neither with beta3 nor with current master.

The Psr LoggerInterface is located in typo3/contrib/Psr/Log/LoggerInterface.php and gets included in typo3/sysext/core/ext_autoload.php

So I guess your troubles are caused by the autoloader.

Could you try to update your TYPO3 sources to the latest version using git master branch, go through the install tool upgrade steps, clear all caches in backend then then reproduce the issue again?

Does the error still occur, when you remove all 3rd party (non sysext) extensions?

What OS do you use?

I'm currently using latest master (TYPO3.CMS-HEAD-6335a24, two days old), and I'm on Ubuntu 12.04LTS, php 5.3.10. Only 1 comm.-extension installed. Gridelements 3.0.0-dev (for TYPO3 6.2.x), plus 3 of my own extensions. Selective disabling doesn't change things. Problem is: It does not happen often (3 times today, on a 12 hour shift).

I am getting this if I clear all caches, the process is not finished and I hit e.g. the tceform of a record in BE ...

I'm also getting this error in latest master.
It occurs after leaving the Backend open for several hours, but I can't reproduce it by setting the sessionTimeout to a low value.
strange thing ....

When setting config value ['BE']['versionNumberInFilename'] = 0 the error disappeared. Of course this is only one of many dependencies.

Maybe a solution:

The reason seems to be that the Psr package is an external package (located under typo3/contrib/Psr).

Therefore the classname to filename mapping is taken from typo3/sysext/core/ext_autoload.php.
But this is only used the first time the classname cache is built (Early Instance Mapping).

In \TYPO3\CMS\Core\Core\ClassLoader::setPackages() about line 391 the cached information on the classmap for that early instances is deleted:

// Clear the runtime cache for runtime activated packages
$this->runtimeClassLoadingInformationCache = array();

This is ok if the class cache is created correctly in "typo3temp/Cache/Data/cache_classes/psr_log_loggerinterface"

But if for some reason the class cache building is incomplete or the cache is not deleted properly we got a deadlock (e.g. "typo3temp/Cache/Data/cache_classes/psr_log_loggerinterface" is missing, but "typo3temp/Cache/Code/cache_core/ClassLoader_<KEY>.php" still exists).

So I commented line 391 in the classloader and this helps. But I cannot say if this will produce unexpected results or is an performance issue.

// HOTFIX - DON'T clear the runtime cache for runtime activated packages
// $this->runtimeClassLoadingInformationCache = array();

I also see this problem constantly with TYPO3 6.2.0beta4. Like others mention, it seems to be some cache-issue: I only see this error after clearing the cache. After some time the site will become available again; of course only until the next time, when the cache is cleared :-(

I can confirm this issue.

When this one shows up? Only if i clear System Cache and click on some page/sysfolder in tree or change action in main content area.
This error won't show up if - after system cache is cleard - we click first some link in modules menu.
So it seems when some module is loaded, some autoloaders are triggered there and class path loaded.

Appears also in frontend.

Steps to reproduce:

• Load page in FE
• Clear the class cache, for example with rm -rf typo3temp/Cache/Data/cache_classes/
• Reload page

I added a relation to #55099, which seems to hit the same sandbag.

This always happens when Code and Data caches aren't cleared together. The class loader caches data in the core code cache and some data in it's own data classes cache.

This can also happen if the classes cache is set up on a "volatile" cache backend like apc where some entries expire (although they shouldn't) and the integrity of the cache is not given anymore.

So please, if you delete caches. Kill the whole typo3temp/Cache folder as one.

Thomas, please have a look into the other issue. I described there how I was able to produce the error also with clearing the whole directory.

Could anyone please verify my "hotfix" mentioned above. For me it reduces errors by incomplete class cash to - let's say - 5% AND - maybe more important - you don't end up in a dead lock! The error vanishes with the next reload of the page. I have not seen any negative side effects so far.

Just to repeat it, I proposed to comment the reset of the class loading cache array in TYPO3\CMS\Core\Core\ClassLoader::setPackages(), just before the return statement.

// $this->runtimeClassLoadingInformationCache = array();

It seems that the current classloader cache implementation with an individual file for each and every class (containing only the class path) is a nice idea but seems not to be suitable for production.

It's painfully slow when the cache is cleared & recreated and it seams to be quite unreliable in situations when the cache is recreated by one request while it is cleared by another (race condition by simultaneous requests). In my opinion it has to be redesigned as soon as possible.

Sven, I fully agree.

The File Cache Backend is really slow. This is one part, but you can choose to change the cache bakcend as you desire by configuration.

The race condition is a general problem of all caches in TYPO3 CMS. I'm working on a general locking solution, to tackle these problems all for once and ever. (#55294)

Link to the blueprint: http://wiki.typo3.org/Blueprints/LockingForCaches

Markus Klein wrote:

[...] you can choose to change the cache bakcend as you desire by configuration.

Alexander Opitz wrote:

The ClassLoader cache does not containing only the class path, it also contains the aliases which need to be added. That is the part that costs us much time.
Over 2400 class aliases on my system to be backward compatible.

Markus & Alexander, thank you for your replies. I couldn't find any config value to completely disable the cache_classes creation.

Beyond the scope of locking mechanisms, it should be possible somehow to merge all that information together, using a reasonable number of cache files, maybe just one.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I think I found the root cause for this issue. The system cache group has been flushed before ext_tables and ext_localconf have been reloaded. This results in the class loader not finding classes/interfaces that have been registered upon initialization. Please test the latest patchset and give a positive review if it solves your issue.

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

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

This bug is not fixed. I get this error message after updating from Typo3 6.1.6 to 6.2.0.
Every page is broken...

This bug is not totally fixed. I get this error message after updating from Typo3 6.1.6 to 6.2.0.
Every page is broken...
Deleting typo3temp/Cache didn´t helped, but deleting the whole typo3temp content helped!

Hi Kurt, please open a new ticket for your issue. We can sort out things there then. Thank you.

in my case clearing the cache AND the opcode cache via installtool solved it totaly!