aoepeople / aoe_classpathcache Goto Github PK

The current method of clearing the APC cache only works well for single-server setups. If the website is run on multiple nodes behind a load balancer then the current method cannot clear the cache on all nodes.

I suggest instead using a filesystem flag. E.g. when loading the APC cache attempt to delete a file named var/classpathcache.flag and if the delete fails then load from APC cache. To prevent another process from storing stale data, rather than immediately delete the APC cache just overwrite it with a new one.

E.g.:

if ( ! @unlink(Mage::getBaseDir('var').DS.'classpathcache.flag')) {
  // load apc_fetch results
}

Hi there,

any reason why the code pool is local? Are you interested in changing that?
Got a lot of conflicts with that :-(

Cheers, Cyrill

on magento 1.9.2.1 with reddis. composer install of master Aoe_ClassPathCache
( can you do a new release all the others seem broken due to modman community/local path issue )

stackadmin@stack-web01:/var/www/magento/shell⟫ php ./aoe* -action clear
Error while cleaning class path cache. Check system.log for details

2015-09-02T08:12:31+00:00 ERR (3): Warning: file_get_contents(http://103.248.190.60/default/aoeclasspathcache/index/clear/k/RXU5SnZBZjhSNEtpSlVOOA==/v/MlBVTERpQ3VxQXN3M3hLUkx2T2QvZz09/): failed to open stream: HTTP request failed! HTTP/1.0 404 Not Found

in /var/www/magento/vendor/aoepeople/aoe_classpathcache/app/code/community/Aoe/ClassPathCache/Helper/Data.php on line 24

Also if I hit the clear button in admin I get a white screen that says "OK"

See FS classmap generator from m2:
https://github.com/magento/magento2/blob/master/dev/tools/classmap/fs_generator.php. The idea is to not cache on the fly but just generate class path cache one time after the deploy. I don't think it is common when new classes are created on production after deploy.

Hello,

We ran into an issue on one of our clients' servers. After we run the Mage cron, all the pages stay blank, and lines like the following appear in our error_log:

[Tue Dec 02 09:34:38 2014] [error] [client 31.160.176.209] PHP Warning:  file_get_contents(/var/www/vhosts/ts-shops.nl/httpdocs/var/cache/classPathCache.php): failed to open stream: Permission denied in /var/www/vhosts/ts-shops.nl/httpdocs/.modman/Aoe_ClassPathCache/app/code/local/Varien/Autoload.php on line 164, referer: http://www.ts-shops.nl/index.php/admin/scheduler/index/key/24a06a7cd7b89deb8d0ed5a0c4fc042f/
[Tue Dec 02 09:34:39 2014] [error] [client 66.249.67.74] PHP Warning:  file_get_contents(/var/www/vhosts/ts-shops.nl/httpdocs/var/cache/classPathCache.php): failed to open stream: Permission denied in /var/www/vhosts/ts-shops.nl/httpdocs/.modman/Aoe_ClassPathCache/app/code/local/Varien/Autoload.php on line 164
[Tue Dec 02 09:34:41 2014] [error] [client 80.100.41.121] PHP Warning:  file_get_contents(/var/www/vhosts/ts-shops.nl/httpdocs/var/cache/classPathCache.php): failed to open stream: Permission denied in /var/www/vhosts/ts-shops.nl/httpdocs/.modman/Aoe_ClassPathCache/app/code/local/Varien/Autoload.php on line 164, referer: http://www.ts-shops.nl/index.php/admin/sales_order_create/index/key/35ebc65ff9cf18ac1eef94895619d61d/

When we delete the classPathCache.php file, all is well again.
We noticed that the file user and group changes when we run the cron.php file, and this has to be the cause of the errors (and thus the blank pages).

When created by calling a webpage:
-rw-rw-r--. 1 apache apache 148817 dec 2 10:42 classPathCache.php
When created after running cron.php:
-rw-rw-r--. 1 ts-83shop psacln 172K dec 2 10:32 classPathCache.php

I tried changing the file permissions to 0777 in app/code/local/Varien/Autoload.php (see below), but this didn't solve the problem.

...
                if (file_put_contents($tmpFile, $fileContent)) {
                    if (@rename($tmpFile, self::getCacheFilePath())) {
                        @chmod(self::getCacheFilePath(), 0777);
                    } else {
                        @unlink($tmpFile);
                    }
                }
...

How can we solve this issue?

Hello there,

Is this related to https://bugs.php.net/bug.php?id=52312 ?

Which disabled the realpath cache is safe_mode/openbase_dir is on?

When developing it happens on occasion that the path is cached but the source doesn't exist any more and thus it throws an error that the class can't be found. After flushing the path cache it works as expected.

It would be nice if the class is automatically revalidated if it can't find the class, it it can't find the class after that it should throw an error. This would be a great help when developing a site.

See http://php.net/stream_resolve_include_path

We need

• a shell script
• a button in the backend (on the cache management page)
• and maybe also a hook for the flush cache / delete all cache command

to delete the cached classpath content (file or apc).

This script can be called after deployments.

• Button to clear classpathcache
• Show if filesystem or apc is used
• Show how many entries are in classpathcache
• Show classpathcache content