[horde] Cache slowly filling up with driver File

[Jan Schneider]

Zitat von Arjen de Korte <arjen+horde at de-korte.org>:

> Citeren Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>>
>>> I use the filebased cache, which stores data on a tmpfs. Works  
>>> fine except for one slight problem, the number of files cached  
>>> doesn't stabilize at all, it keeps growing.
>>>
>>> Right after cleaning the cache partition, almost all cached files  
>>> are listed in the 'horde_cache_gc', so eventually these will be  
>>> caught during garbage collection. But I also see the number of  
>>> files that are *not* listed growing every day (which as far as I  
>>> can see, means these will never be removed).
>>>
>>> I see that in many places, no explicit lifetime is set when  
>>> storing an entry in the cache (for instance, the information  
>>> retrieved by the weather info), so these will never be GC'd as  
>>> only files with non-zero lifetime will make it into the  
>>> 'horde_cache_gc'.
>>
>> This isn't 100% true. When a cache value is requested from the  
>> cache, a $lifetime parameter can also be supplied. So, e.g., in the  
>> case of Horde_Service_Weather, we specify the $lifetime when  
>> reading the cache. If the $lifetime expired, then the cache library  
>> will (in the case of a file based backend) unlink the cache file.  
>> Granted, since this only happens when the specific cache key is  
>> requested, I see how this could lead to certain cache files perhaps  
>> never being GC'd if, again using Horde_Service_Weather as an  
>> example, weather location was requested once, and never requested  
>> again.
>>
>>> Wouldn't it be a better idea to let *any* file stored in the  
>>> filebased cache timeout to prevent them from piling up?
>>
>> For some data, sure, it might make sense to add a $lifetime  
>> parameter to the set() method if it doesn't already exist, but not  
>> all data necessarily should be automatically expired.
>
> I put a Horde::debug statement in the File.php set() method that  
> logs data with lifetime zero (ie, cache entries which will never be  
> GC'd). The resulting log file worries me a little, since all entries  
> seem to be Horde_History_Log ones. Since the data is also stored in  
> the database, I think storing them in the cache permanently is not  
> needed and instead the default cache lifetime would be appropriate  
> for this data:
>
> --- History.php.orig    2014-11-18 20:16:53.300494861 +0100
> +++ History.php 2015-04-27 21:57:01.069877539 +0200
> @@ -169,7 +169,7 @@ abstract class Horde_History
>
>          $history = $this->_getHistory($guid);
>          if ($this->_cache) {
> -            $this->_cache->set('horde:history:' . $guid,  
> serialize($history), 0);
> +            $this->_cache->set('horde:history:' . $guid,  
> serialize($history));
>          }
>
>          return $history;
>
> --- History/Composite.php.orig  2014-11-18 20:16:53.300494861 +0100
> +++ History/Composite.php       2015-04-27 22:01:07.033756773 +0200
> @@ -115,7 +115,7 @@ class Horde_History_Composite extends Ho
>              $history = new Horde_History_Log($guid, $data);
>
>              if ($this->_cache) {
> -                $this->_cache->set($cid, serialize($history), 0);
> +                $this->_cache->set($cid, serialize($history));
>              }
>          }
>
> For many cache backends this is probably not an issue (since they  
> will automatically evict old cache entries), but the filesystem  
> cache relies solely on the GC to do this.

Funnily this was originally a Horde_Memcache, and then a  
Horde_HashTable implementation. I later converted it to use  
Horde_Cache instead which was when the infinite lifetime was added too.
Fixed in Git.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject