[Tickets #13085] Re: Use memcache instead of distributed hashtable in $conf[cache][driver]

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13085
------------------------------------------------------------------------------
  Ticket             | 13085
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Use memcache instead of distributed hashtable in
                     | $conf[cache][driver]
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Assigned
+State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Michael Slusarz
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2014-03-31 13:44) wrote:

>>> That's true, but would it hurt to set the lifetime? All cache drivers
>>> will default to a lifetime of '0', which means data will never be GC.
>>
>> Memcache does not need GC and, thus, doesn't need lifetimes.
>
> This remark wasn't limited to memcache. Currently, the data that is  
> stored in the cache by Horde_Service_Weather doesn't set a lifetime,  
> which (if I understand correctly) means that it will never expire  
> stay in the cache forever.

It means it will never be GC'd. It will "expire" and be removed from  
the cache if the code enforced lifetime (via ::get()) is reached. GC  
is ONLY for the backend and even then there is no guarantee that a  
given bit of data WILL be removed once the GC is reached - it only  
flags it as being available for GC the next time the backend triggers  
it's GC routine.

> So while memcache may not need this, other cache drivers may in  
> order for prevent the cache from filling up. For instance, with  
> WeatherUnderground (if users don't configure a location in their  
> preferences) the GeoIP lookups of mobile users may result in loads  
> of entries.

It depends. Only when a lifetime value of '0' is passed does this mean  
that it is never marked for GC. If it is omitted (therefore passing a  
null), it is marked for GC based on the configured default GC lifetime.