Error handling in Cache::Memcached
george at omniti.com
Wed Jul 12 20:33:11 UTC 2006
>> The problem with this is that since I still don't know why my get()
>> failed, I would need to call this method unconditionally before every
>> operation. That's very expensive. Optionally die()'ing seems much more
> The application doesn't need to know why the get() failed. Check the
> mailing list archives. This has come up a number of times for two
> different reasons:
> 1) Clients used to, some still, detect when a server goes down, then
> redistributes keys.
> 2) Figured out that 1) was a bad idea, because the keys get
> redistributed again when the server comes back up, or constantly if it
> flaps. Tons of cache misses! Better to treat everything as a cache miss
> and have a monitoring service actually let you know if memcached is lost
> and gone forever, rather than cause tons of cache misses to redistribute.
I understand that using this information to base decisions about key
redistribution is probably unwise. Presumably this is why the
auto-rehashing is toggleable.
That said, the value in having application code know whether or not a
server is available is still important. If for no other reason than
your application is _the_ best place to detect intermittent errors in
the components it talks to.
> Also, hey George :P I was at CCI after you left.
More information about the memcached