I know it's been posted numerous times already, I've done as much troubleshooting as I can, I'm now turning to the community for help. I've already posted this same content to Bug #9667, since it seemed relevant.
Needless to say, the "Error caching lexicon topic" error is driving me crazy for our MODX instance.
We initially installed the product to an intranet site, and had no issues.
Since migrating to our public Web domain, the issue has been continuous and pervasive. I've checked the core.config files to make sure the Web host info is correct, and it is.
We're running three contexts, routing traffic using bertoost's GatewayManager plugin. I've set up the secondary contexts' site_start, site_url, http_host, etc.
I'm consistently seeing errors like the following:
[2013-10-11 14:55:07] (ERROR @ /connectors/resource/index.php) Error caching lexicon topic lexicon/en/core/default
[2013-10-11 14:55:11] (ERROR @ /connectors/system/settings.php) Error caching lexicon topic lexicon/en/core/setting
[2013-10-23 09:28:07] (ERROR @ /connectors/lang.js.php) Error caching lexicon topic lexicon/en/core/resource
[2013-10-23 15:05:16] (ERROR @ /connectors/element/propertyset.php) Error caching action map mgr/actions
[2013-10-24 14:49:41] (ERROR @ /connectors/resource/locks.php) Error caching lexicon topic lexicon/en/core/default
[2013-10-24 15:41:36] (ERROR @ /connectors/layout/modx.config.js.php) Error caching lexicon topic lexicon/en/core/resource
Sometimes the log will throw one of the above errors and the manager will continue to respond normally; sometimes it will start throwing the "Unexpected Token" error (see attached screenshot). When I check the "network" tab in Chrome developer tools, basically what happens is that after the cache error happens, our system will start throwing 404 and / or 502 errors. It seems like at some point, the cache corruption causes requests to use too much memory and then the request thread fails before it can return a result.
In most cases this appears to only affect the manager, but yesterday I saw the 502 error on the front-end for one of our contexts. The initial index.php controller would return a 502 error for pages on the site. Sometimes you could refresh the page and the request would complete, but then move to another page and the error would happen again.
Our system:
Revolution 2.2.8-pl Traditional
Gentoo 2.6.34-r6
MySQL 5.1.56
PHP Version 5.3.27-pl0-gentoo
PHP memory limit is set to 128
Max Execution Time 120
- Compress JS and Compress CSS are both disabled in the MODX system settings.
The core/cache/ folder is set to 755 permissions, where Apache is the owner and group.
We are running memcache(d) on these Web servers.
We are running a load-balanced configuration for the Web servers, but the MODX instance is only connected to one database.
I am not the primary server administrator for the systems hosting our MODX instance, but I have a direct line of communication with him. If I need to get some apache error logs, etc. from him I likely can, he would need to block out the time to retrieve them.
I just want to state that our organization loves the potential of MODX, but cannot wholeheartedly endorse it for our major public Web site because of this issue. Currently we're using it for several subdomains / microsites, but would love to move our major public Web presence on to it, but at this point it's a complete non-starter due to this issue.
For now I've completely disabled lexicon caching to see if it stops this problem. We don't have any intention of using internationalization features in the near future, so if disabling the lexicon cache makes things more stable we're willing to take the performance hit in the manager, but this is a real problem for us. I would love, LOVE to give MODX a whole-hearted "thumbs up" to my management team, but simply can't right now.