MODX having a hard time on Rackspace Cloud Sites

I had cleared the core/cache directory since the site had become nonoperational before the install, it probabably rebuilt itself before I completed the install. I now have 2.2.7 on three RS Cloud Sites with the core/cache completely emptied out. All three sites are very low traffic.

There are cache errors on one of the sites since but the other two are clean so far.

[2012-12-13 15:53:16] (ERROR @ /index.php) Could not retrieve data to cache for resource 177
[2012-12-13 15:56:28] (ERROR @ /connectors/browser/directory.php) Error caching lexicon topic lexicon/en/core/source

All three sites seem to have gone south. I was giving them a workout by browsing each of them and they are taking a long time to respond or timing out now.

Site 1 Log:

[2012-12-13 16:14:26] (ERROR @ /manager/index.php) Could not cache system settings.
[2012-12-13 16:14:28] (ERROR @ /manager/index.php) Could not cache context settings for mgr.
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/default
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching action map mgr/actions
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/dashboard
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/topmenu
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/file
[2012-12-13 16:14:29] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/action
[2012-12-13 16:14:30] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/core/login
[2012-12-13 16:14:31] (ERROR @ /manager/index.php) Error caching lexicon topic lexicon/en/gallery/default
[2012-12-13 16:14:37] (ERROR @ /index.php) Could not cache context settings for web.
[2012-12-13 16:14:38] (ERROR @ /index.php) Could not cache source data for 1.
[2012-12-13 16:14:38] (ERROR @ /index.php) Error caching lexicon topic lexicon/en/wayfinder/properties
[2012-12-13 16:14:40] (ERROR @ /index.php) Could not get table name for class: modFileMediaSource

I removed a bunch of these to cut out the redundancy.

Site 2 log:

[2012-12-13 16:27:39] (ERROR @ /connectors/layout/modx.config.js.php) Error caching lexicon topic lexicon/en/core/resource

Site 3 log was empty. I had to delete core/cache in order to access Site 2 and Site 3 again. [ed. note: pyrographics last edited this post 13 years, 9 months ago.]

Since this is a multi-node environment using a shared NFS mount, do accounts on RS Cloud Sites have any access to node-specific local file systems where they could write node-specific caches? If so, configuring the cache_path is another option that might help mitigate this issue. I'm unfamiliar with the details of RS Cloud Site accounts however, so not sure if that is even a possibility.

Well, I would think that it must have some kind of shared location for such things as session files. That caused some problems years ago when hosting companies were first moving to distributed servers and sessions were getting lost. Everyone seems to have gotten that sorted out.

For normal php sessions you set your own session_save_path through .htaccess. Not sure about caching.

To save sessions on RS Sites you need to add this to .htaccess

php_value session.save_path /mnt/stor0-xxx-xxxx/xxxxxx/www.xxxxxxx.com/web/sessions
php_value session.save_handler files

They also recommend turning off XCache, to see if this causing any problems...

php_flag xcache.cacher off
php_flag xcache.stat off

php_flag xcache.cacher 0
php_flag xcache.optimizer 0
php_flag xcache.coverager 0

php_flag xcache.size 0
php_flag xcache.stat 0
php_flag xcache.var_size 0
php_flag xcache.var_cacher 0

Unfortunately none of these work to fix the issues. As I've already tried.

The problem is not precisely the same in any case, as it appears to be a problem with file locking not being supported here. MODx can't be the only application that uses file locking for handling dynamic files such as cache files, so I'm sure something will eventually be worked out.

I downloaded the WP Super Cache plugin for Wordpress and looked at their flock code. While RS Cloud Sites says to turn on use_flock, the function on line 185 of wp-cache-phase2.php appears it off regardless of the config setting and instead uses sem_get if the function exists. They simply replace flock($mutex, LOCK_EX); and flock($mutex, LOCK_UN); with sem_acquire($mutex); and sem_release($mutex); respectively. The sem_get function does exist on RS Cloud Sites.

Nice detective work @pyrographics

I'm excited that something is happening on this front. I eagerly tried 2.2.7 on one of my affected sites. I had a few hiccups during the upgrade (kept finding a few files or folders with improper permissions), but I was able handle them manually. However, the end result is no different. This site is still not running wayfinder or IF, so half the page is still no rendering. I will try this on another site that frequently goes down to see if I get different results.