ZF-9850: Stop caching $_options in zend_translate to avoid warning of "Potential cache slam averted for key "

Issue Type: Improvement Created: 2010-05-17T09:27:39.000+0000 Last Updated: 2011-01-31T06:52:40.000+0000 Status: Resolved Fix version(s): - 1.10.6 (22/Jun/10)

Reporter: Ankit Shah (akshah123) Assignee: Thomas Weidner (thomas) Tags: - Zend_Translate

Related issues: Attachments:



At present, Zend_Translate adapter is caching $_options parameter. I do not see any performance improvement of this feature but it does lead to bunch of "Potential cache slam averted for key " with apc cache options.

Consider following scenario:

Zend_translate is passed in an option to log missing translations to a file on the server. Zend_translate is set up in the beginning for all incoming requests and put in the registry so that views can later access them. Apc is used as caching for zend_translate.

Since parameter for log is created each time, zend_translate adapter thinks the options value have changed and try to save it in the cache with the same key. Since, there are several requests in the same second, Apc does not save the cache and throws the warning of "Potential cache slam averted for key Zend_Translate_TMX_Options.

I have tried to cache $log in the cache so that zend_translate does not think its changed but that does not work as the $writer object has stream to a file which does not work with cache.

In my opinion, there are no advantages of caching $options parameter as they are already in memory before they are passed within zend_translate.


Posted by Thomas Weidner (thomas) on 2010-05-17T13:42:33.000+0000

You are the first in 4 years who requests that Zend_Translate should stop caching because the cache throws notices.

Zend_Translate caches the translation file with all options. This is done for every translation file which is added because for each file the options change.

The reason for this behaviour is not performance but the reason that translations must be coupled with their options. Otherwise it would not be possible to retrieve the cached translations from the cache.

When you are translating then there is nothing written into the cache. You can have as much untranslated message as you want... they will not be written into the cache.

Posted by Ankit Shah (akshah123) on 2010-05-17T14:05:33.000+0000

Hi Thomas,

Thank you for your quick reply. I think either I am not understanding something or I am unable to explain the issue properly.

I am not asking that Zend_Translate stop caching altogether. I actually find it quite useful for caching translations themselves. I just didn't see the point in caching the $_options attribute in Zend_Translate_Adapter abstract class. This cached value is only accessed or set in three places.

  1. constructor: here if there is options already in cache, they are retrieved as used to set the member options value. Then setOptions is called which checks to see if the array has different value than already stored. If yes, it updates the cache with the new options array.
  2. setoptions:
  3. setlocale: this updates the locale value in options and resets the cache parameter with the options.

From what I can tell, this cached value is not retrieved anywhere except in the constructor. If that is the case, I do not see how options could possibly be coupled with their translations.

The problem I have is since $log parameter in options is a new instance (though has the same values as before), it thinks the options array is dirty and tries to update/save the array again which generates the notices/warnings as there are way too many save requests for the same key.

Again, I could be missing a big part here as you obviously have a lot better understanding of this component. However, as far as I can tell, removing the code that caches this parameter would have no effect on behavior of zend_translate as long as $options array is passed in every time zend_translate is initialized.

Posted by Thomas Weidner (thomas) on 2010-06-09T14:45:58.000+0000

Closing as won't fix.

Erasing caching for options would negotate usage within Registry, Application or Bootstrap. This is a no-go and will therefor not be reverted to non-functionallity.

Posted by Ankit Shah (akshah123) on 2010-06-10T08:08:53.000+0000


I am lost. I will really appreciate if you can point me in the direction. I have tried going through the code & documentation but have not found anything that would suggest that caching options would be required. I know that I am missing something obvious and therefore probably wasting your time.

I request that you bear with me and perhaps show me a scenario where removing cache on options would break the application or reduce functionality. What do you think I should do to perhaps understand the module a little better? Is there a forum where I can request someone to explain this?

Posted by Menno Dekker ( on 2010-06-18T02:48:26.000+0000

I have the same problem on a recently updated system... apc is not happy when you do

<pre class="highlight">
$translate = new Zend_Translate('gettext', $sPathPrefix . '/languages/', 'nl');
$translate->addTranslation($sPathPrefix . '/languages/', 'en');

as it tries to write Zend_Translate_Gettext_Options twice in a very short time. Also I think it is silly to first process options in the constructor and then load from cache. Good behaviour would be to check if we have a valid cache and if not to create the options and cache them. I think it is just left over code that should be removed. Commenting out the two references to a cache id with _Options in it didn't break anything as the important cache is the cache for the specific translation.

Posted by Thomas Weidner (thomas) on 2010-07-04T07:18:48.000+0000

@Ankit: Using Bootstrap with Application helper would lead to first loading of translation. But when Bootstrap is processed again it would, in case that there is no cache, mean that the whole tree has to be searched again. Options hold not only manually set options but also the active locale from the last call.

When you think that caching is not necessary then do not attach a cache.

@Menno: In your case options are not load from cache. There is only ONE place where options are load from cache and this is at contruction. In your case the cache did not exist before initiation. When you call it twice then the second call would load from cache which is correct. Not loading from cache would mean that cache is useless.

Even if you did not read the code correct, the cache is ONLY written when there are changes within the data which has to be cached.

And no: Also the options cache is necessary. Only because you think that you don't use it within your code it does not mean that other components also don't use it.

When I would try to save the cache 4 times within a second APC should not report problems as long as the saved data is different from the already saved ones. In your case the options change from line one to line two. Therefor the changed options are saved which makes APC report a problem.

Posted by Jasper van Wanrooy (jvanwanrooy) on 2011-01-31T06:52:34.000+0000

@Thomas: I don't understand why the options array should be stored into the cache. It is relatively simple object. Every time a locale is being set, the cache is saved. However, all requests have different locales, so the options are stored every request again. When using the File cache backend in a high volume environment, it causes a lot of errors about being unable to chmod, unlink, etc a file, because the file is written each time again.

What exactly is the reason to cache the options array?

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.