How does MaxMemory work with this module.

For what it worth Redis is a persistant database: this means that it won't give you features such as LRU expiration of entries. Memcache is way better at this level. Another problem is that when Redis hits the memory limit it stops writing and that is all. It only allows read until YOU empty it or add more RAM.

I'd be happy to add such memory checks, but that's not this module responsability to do so.

Now considering that fact about Redis (correct me please if I'm wrong in anything, Redis evolves very fast) I did discuss this problem internally with a few coworkers, and it happens that the niciest solution would probably be to set a lifetime for *all values* without exception, which could vary from a few weeks to years depending on the use case, environment, site admin.

So we all agree your solution is the right one, let's implement it :)

This will need to be implemented globally with possibility to set expiry time per bin.

Please note that implementing this in the backend directly is only a safety workaround: in real life you can configure the "cache_lifetime" Drupal core variable to any possible value and all your cache entries will be temporary de facto.

But because I like challenge and because most people won't configure something that isn't really well documented I will implement this failsafe.

If you need it to be more tricky than what I exposed upper (i.e. set a default very long lifetime, configurable per bin) please speak now.

AFAIK Redis does have LRU built-in support - at least in current stable:

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key accordingly to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
#
# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are not suitable keys for eviction.
#
#       At the date of writing this commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort
#
# The default is:
#
# maxmemory-policy volatile-lru

# LRU and minimal TTL algorithms are not precise algorithms but approximated
# algorithms (in order to save memory), so you can select as well the sample
# size to check. For instance for default Redis will check three keys and
# pick the one that was used less recently, you can change the sample size
# using the following configuration directive.
#
# maxmemory-samples 3

Oh nice, didn't knew about that.

Still I'd be confortable with implementing the all-keys-must-expire-one-day feature in the module, it's still be a failsafe for people not using their Redis instance only for cache.

I think that what omega8cc pointed out is that you can also configure Redis to drop permanent keys; This is probably not something wise to do if you use Redis for something else than caching.

I think that in #6 you are rephrasing some details that I gave. What I propose is to have one variable per bin (exactly the same as the flush mode) for default TTL for permanent items, which then will become non perment; If the variable is not set, the module will use something like 3 months or so (globally configurable of course) and which could be set to "0" (make them permanent back again).

For example, we could imagine this configuration:

// Make CACHE_PERMANENT items being really permanent
$conf['redis_ttl] = 0;
// OR
// Make CACHE_PERMANENT items live only three months
// (parsing is easy to implement using \DateTime) 
$conf['redis_ttl] = "3 months";

// Make CACHE_PERMANENT items in 'cache_page' bin live for one year
$conf['redis_ttl_cache_page'] = "1 year"

// All non configured bin would inherit from the global
// 'redis_ttl' value

What do you think of that? Would it solve your problem?

Ok got this right, I think.

See this commit http://drupalcode.org/project/redis.git/commit/f9f0bf9 (unit tests are don't fully cover but I think it's enough).

Please read documentation about the new feature there: http://drupalcode.org/project/redis.git/blob/refs/heads/7.x-2.x:/README....

Releasing 7.x-2.6 within the day.

Release 7.x-2.6 is 'en route' and coming soon containing this bugfix.