Revolution: Error caching lexicon topic

[sebastian-marinescu]

Bug report

Summary

Occasionally, seldom and still regularly, I get the error Error caching lexicon topic in the logs.

I'd really like to know what is causing this. Why is this happening?

Step to reproduce

Use MODX, best with some Extras active.

Observed behavior

Sometimes nothing, but the log-message. Sometimes really no translated lexicon-tags in the front-end, which go away by itself, or after clearing cache. Sometimes blank page?

Expected behavior

Working lexicon system.

Environment

All versions I've been using so far, in all environments.

Related

https://forums.modx.com/thread/82511/error-caching-lexicon-topic
https://community.modx.com/t/error-caching-lexicon-topic/3154/2
https://github.com/modxcms/revolution/issues/7324
https://github.com/modxcms/revolution/issues/9667

[Jako]

One source of this issue would be a lexicon file that does not create a $_lang array.

Put return false; in one lexicon file or create a lexicon file without any content. After clearing the cache, that error message should be triggered. Maybe you have a file like this somewhere in the tree. But the name of the file should be logged.

Sorry this creates a different error message:
[2019-02-13 11:15:49] (DEBUG @ /somepath/core/model/modx/modlexicon.class.php : 259) An error occurred while trying to cache lexicon/de/core/trash (lexicon/language/namespace/topic)

[sebastian-marinescu]

Thank you very much @Jako for this information.
I'll test/check this soon and will report back.

[sebastian-marinescu]

So in the last 3 days these logs accumulated:

[2019-01-27 18:14:31] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/babel/default
[2019-01-28 20:00:04] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/de/mxcalendars/default
[2019-01-28 20:00:04] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/batcher/default
[2019-01-28 20:00:05] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/de/core/trash
[2019-01-29 07:40:20] (ERROR @ /somepath/www/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/en/bigbrother/mgr

I've pasted and linked the contents of these files so you can check with me.
The title of the paste-bins are the paths to the files.

To me, these files all seem fine.
Also interestingly in some cases it tries to cache the "en" version,
although the manager and website are set up to "de".

Why is it still logging this error?
What other causes can this error have?

[jonleverrier]

Not saying it's related, but out of interest, what server stack are you using @sebastian-marinescu ?

[JoshuaLuckers]

Sometimes I experience the same issue. It's totally random..

[muzzwood]

I get these all the time too and yes it's seemingly random. I'd also love to find out what's causing it.

[Jako]

Could that be caused by file locking?

[meshkov]

I have this problem too:
[2019-02-13 14:12:48] (ERROR @ /somepath/core/model/modx/modcachemanager.class.php : 349) Error caching lexicon topic lexicon/ru/core/default [2019-02-13 14:12:48] (ERROR @ /somepath/public_html/core/model/modx/modcachemanager.class.php : 399) Error caching action map mgr/actions
But I also have Error caching action map mgr/actions

[arjen-t]

I faced the same odd problem as well. I played around with the lexicons values. It seems to like that some character parsing issues is causing this issue.

Situation 1:
$_lang['some_uber_label'] = 'Hi this is English';

No caching issues appears

Situation 2:
$_lang['some_uber_label'] = 'Hi this is English isn\'t great?';

Random caching errors

Situtaion 3:
$_lang['some_uber_label'] = "Hi this is English isn't great?";

So far during testing no caching errors.

It seems to be that the escape single quote is randomly be parsed wrong into the caching file.

Maybe other people can test this as well?

[muzzwood]

Just woke up to a site which overnight seemed to have a huge error log with these Error caching lexicon topic errors.
Every time I loaded a manager page a lot more of these errors appeared.

• I checked file and directory permissions which were fine.
• Clearing the cache didn't affect it.

Manually deleting everything inside the cache directory DID fix it (at least for now). Though no idea why.

[Ibochkarev]

Hello. is there any progress in solving this issue?

[JoshuaLuckers]

We need a situation where we can reliably reproduce this issue.

[wfoojjaec]

This happens, when simultaneous writes into same cache file happen. To reproduce it, you need two concurrent requests to try and write into lexicon (or any other cache).

[wfoojjaec]

Default xPDOFileCache lockFile method does not work well, especially with php-fpm multithreaded setups. Even in cases, when instructions follow one-by-one, e. g. is_dir( $pathname = dirname( $filename ) ) || @mkdir( $pathname, 0777, TRUE ) such issues can happen.

Using use_flock option along with custom values for xPDO::OPT_CACHE_ATTEMPTS and xPDO::OPT_CACHE_ATTEMPT_DELAY in system/context settings can reduce number of errors to almost zero.
https://github.com/modxcms/revolution/blob/53c9fdd4ece5ae0a9cffd00477ba93af931020a0/core/xpdo/cache/xpdocachemanager.class.php#L233

This error level can be changed to xPDO::LOG_LEVEL_WARN, because eventually a cache file is written anyway by one of the threads.

[sergant210]

@JoshuaLuckers It's not easy. I'll try to describe the problem. When you refresh the manager page many requests are sent. If lexicon cache is empty (for example, after changing any system setting) the modCacheManager try to renegerate the cache for all topics. And in some cases, the cache managers from different requests try to create a file for the same topic.

I think the lazy regeneration of lexicon cache will solve the problem. And the level of this error have to be changed to Warn level.

[opengeek]

The default locking only works on systems that have flock available. If you are working with a filesystem that does not support flock, such as a shared network volume, you need to disable the use_flock setting. Regardless, the error message usually means that another thread is regenerating the cache already and any new ones that have not acquired a lock while it is being generated have been prevented from writing the cache simultaneously.

[rthrash]

This issue has been mentioned on MODX Community. There might be relevant details there:

https://community.modx.com/t/error-caching-lexicon-topic/3154/3

[sebastian-marinescu]

Default xPDOFileCache lockFile method does not work well, especially with php-fpm multithreaded setups. Even in cases, when instructions follow one-by-one, e. g. is_dir( $pathname = dirname( $filename ) ) || @mkdir( $pathname, 0777, TRUE ) such issues can happen.

Using use_flock option along with custom values for xPDO::OPT_CACHE_ATTEMPTS and xPDO::OPT_CACHE_ATTEMPT_DELAY in system/context settings can reduce number of errors to almost zero.
https://github.com/modxcms/revolution/blob/53c9fdd4ece5ae0a9cffd00477ba93af931020a0/core/xpdo/cache/xpdocachemanager.class.php#L233

This error level can be changed to xPDO::LOG_LEVEL_WARN, because eventually a cache file is written anyway by one of the threads.

Thank you _very_ much @wfoojjaec for shedding some light on that matter!

I'm also voting for changing it to a warning, as it is not a real error.