Standard drupal cache_set uses unixtime is $expire parameter, there is only one bug #230374: FAPI sets cache_form entry expiration incorrectly that ignores it.
All functions of cache backends accept $expire(TTL) as seconds difference only in memcache that calculates (if more then 2592000 seconds then it is a timestamp) so we need to set ttl a different way than now.

My proposal is to calculate TTL for store functions as mentioned #262830: Fixed version for 6.x

Another thoughts about CACHE_TEMPORARY which is -1. So you set a 180 sec TTL for it but I think it should be same as variable_get('cache_lifetime', 0) as in system.admin.inc (drupal 6). But we need an ability to clean them on cron or as in original cache.inc in cache_get (flag cache_flush)

I'm using a lookup tables with index of all temporary values as permanent but marked with expire = -1

Any thoughts, ideas?

Comments

slantview’s picture

slantview CreditAttribution: slantview commented
Status: Postponed (maintainer needs more info) » Fixed

I think this is already fixed.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented
Status: Fixed » Postponed (maintainer needs more info)

No it's not fixed because TTL for TEMPORARY still 180 so most of time $lookup have keys without data in cache.

Example:
1) cache_set - stores TEMPORARY for 180s in backend and $lookup filled with $key
2) After 180 item expires in backend but $lookup still holds a $key

Proposal:
- Store TEMPORARY as PERMANENT as in core cache.inc (TTL= 0)
- $lookup[$key] set to $expire (as param of cache_set)
- Clean TEMPORARY items on flush() by checking $lookup[$key]

Thoughts?

Jonah Ellison’s picture

Jonah Ellison CreditAttribution: Jonah Ellison commented
Title: Few things about set functions » Obey "expire" value on cache_clear_all(), like Drupal core
Version: 6.x-1.0-beta4 » 6.x-1.0-beta8
Status: Postponed (maintainer needs more info) » Active

I'm posting this here since opening a new issue would be a duplicate.

If "expire" is set to a future timestamp or to CACHE_PERMANENT, then the cache should not be deleted on flush. (http://api.drupal.org/api/function/cache_clear_all/6).

An example of this being problematic is when cron.php runs and deletes all values in cache_form, which CCK depends on when generating multiple fields for forms. See: #406050: CCK Add Another Item causes fields to disappear

Here is the solution I've implemented for the forked version of Cache Router in Authcache:

For each engine's lookup table, instead of storing "1" as the value, store the expiration.

// Set key to $expire so we can keep track of the bin
$lookup[$this->key($key)] = $expire;

Then on flush(), check the expiration. Here is an example for the APC engine:

// Cycle through keys and remove each entry from the cache
foreach ($lookup as $k => $expire) {
  if($expire != CACHE_PERMANENT && $expire < time() && apc_delete($k)) {
    unset($lookup[$k]);
  }
}

For cache.inc, I don't think TEMPORARY should be store as PERMANENT (TTL= 0) because of this.

Related:
#463046: APC engine sets timestamps as TTL when not using CACHE_TEMPORARY or CACHE_PERMANENT

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented

This is a good promising solution but this still holds lookup tables which is expensive (lookups is bottleneck without good locking api)

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost commented

suppose apc_delete() should be removed from if () because unpredictable result for example when item already expired but value still in lookup

http://php.net/manual/en/function.apc-delete.php

Jonah Ellison’s picture

Jonah Ellison CreditAttribution: Jonah Ellison commented

Ah, yes, good call, andypost.

slantview’s picture

slantview CreditAttribution: slantview commented
Status: Active » Fixed

I committed this for memcache and apc. Need to roll out to the other engines, but I really like this idea. Thanks guys.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Quarantine’s picture

Quarantine CreditAttribution: Quarantine commented

Silly question, but how do I check which caching mechanism/module my Drupal or CentOS server is using? I'm having the same problem with #406050: CCK Add Another Item causes fields to disappear.

kevinsiji’s picture

kevinsiji CreditAttribution: kevinsiji commented

Hi,
As this is committed to memcache and apc, what if the site is just using the Drupal core caching mechanism. Is there any bug filed against the core caching mechanism to solve this issue?

Also I think all the below issues are related to (or duplicate) this issue.
http://drupal.org/node/1167720
http://drupal.org/node/406050
http://drupal.org/node/1167720

giaza’s picture

giaza CreditAttribution: giaza commented

I have the same problem but using the file engine.
I would like to use authcache and cacherouter at least for node/add but when i use add more item on a multiple cck field the whole fieldset disappears.
What fix should I apply to the file engine?

Thanks in advance