novembit / i18n Goto Github PK

I'm curious about the '_mutex' files that are generated when a GoogleException occurs. It seems to be there to identify when an exception occurred for a specific translation, so as not to re-try that particular translation again for a while (API usage preservation). That's good, however, after the time period passes and the call is retried, there doesn't appear to be anywhere that garbage collects it.

Perhaps the mutex file should be removed before it goes to retry, to prevent the potential for a directory on the server filling up with thousands of redundant timestamps and causing other problems?

OK, so mutex files in a directory somewhere on the web host are great to keep things simple for an average single-host application or local developer environment.

However, in a larger production/clustered/containerised environments, such as we have deployed, we are running 'i18n-hub' containers in a 3-pod deployment for redundancy and load balancing. This means it would create mutex files in the pod filespace of each of the three pods before each pod starts to back off of those requests. Not a big issue, but also not ideal.

My suggestion (well, requirement really) is to make this component more configurable. I suggest to replace the 'file_put_contents' and 'file_get_contents' lines and the '_getMutexPath' method with more generic '_getMutex' and '_setMutex' calls instead, which can then be used to provide a configurable back-end, such as Redis (ideally), that could be used by all three pods to co-ordinate their mutexes.

2020/04/17 07:39:27 [error] 10#10: *8 FastCGI sent in stderr: "PHP message: PHP Warning:  file_put_contents(/var/www/html/vendor/novembit/i18n/src/system/../../runtime/214784bd04626d88cb43faaaaab27404_mutex): failed to open stream: Permission denied in /var/www/html/vendor/novembit/i18n/src/component/translation/method/Google.php on line 157" while reading response header from upstream, client: 10.42.11.12, server: , request: "POST /i18n/rest/v1/translate?api_key=GmYg90HtUsd187I2lJ20k7s0oIhBBBAv HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.4-fpm.sock:", host: "i18n.brandlight.org"

The 'runtime' folder should probably be /wp-content/uploads/i18n or somewhere else that is more likely to have (shared) write access. Many (production) sites will lock down write access to the plugins folders once deployed for security reasons.