Elaborate please.

We would like the mmc_hash() function to be accessible from PHP.

Specifically, we want to be able to check whether a get() or set() operation is using the intended server X or whether it's being remapped to another server because X is down.

In the latter case, one of the things we want to do is lower the expiration time to reduce chance of stale data.

Would this be similar to?

http://lists.danga.com/pipermail/memcached/2006-August/002603.html

My thoughts at the time was to add a memcache.max_failover_ttl ini setting which would cap the ttl in the event of failover, the purpose being to lower the chance of stale data when the server goes up and down before the remapped keys have expired.

Would an ini setting such as this solve your problem?

Addressing this specific problem would be a very good idea.

Instead of using a global ini setting, however, I would prefer to have it local per Memcache object. That way, it's possible to access different memcache pools with different requirements. For example, our html cache would have larger failover-TTLs than our data object cache.

A TTL of 0 could then have the meaning that no failover takes place on that Memcache object.

I still think a hashing function would be useful for people with *really* custom requirements, but the above would pretty much solve our problem.

This would also be helpful in allowing people to implement libketama:

http://amarok.kde.org/blog/archives/363-libketama-a-consistent-hashing-algo-for-memcache-clients.html

Though I have my own complaints with how it loads server. Ideally, the memcache PECL extension would do two things:

1.) Allow the use of ketama

2.) Allow key salting *after* it's been hashed to a specific function. This would help with stale data on failover/recovery. If server A stores "baz" in key "foo", fails, key "foo" is hashed to server B and "php" is stored into the key, server A returns, a new value is written to key "foo" on server A and then A fails, you're left with the stale value of "php" on server B when it's hashed over to server B on the second failover.

I'd like to see the key salting added as an argument in the addServer() command. I have a somewhat buggy patch for this that I wrote for us at Digg. It works fine from the CLI, but fails when ran from Apache. I'm no C guru so it's probably something simple if you're interested in looking at it.

Actually pecl/memcache in CVS supports consistent hashing as of yesterday, you can checkout and build a copy like

 cvs -d :pserver:cvsread@cvs.php.net:/repository checkout pecl/memcache
 cd pecl/memcache
 phpize
 ./configure
 make && make install

You also need to set an INI entry like

 memcache.hash_strategy = consistent

The consistent hash strategy is implemented using CRC32("server:port") instead of using MD5 as libketama or SHA1 as Set::ConsistentHash, though this might change in the future when a standard has been agreed upon.

If you want to avoid stale data when servers are flapping the best way would probably be to set the INI entry "memcache.allow_failure" to 0, this disables failover entirely.

If data-integrity is extremely important, you could also implement the "status" and "failure_callback" parameters to addServer() in order to track server state in an external database so as to make sure that servers are properly flushed before being used again.

//Mikael

Hello, is this bug fixed in the current memcache 3.0.0?

In addition, will there be a stable Windows build for this version?
http://pecl4win.php.net/ext.php/php_memcache.dll

No, this bug is not fixed. I'm also not really clear on what's required, it would help with some use-case scenarios

Version 3.0.0 should be able to compile on windows, but I don't have the resources to try it out myself. I'm hoping someone else might have the time to look over memcache.dsp and adjust it to compile properly.