Error handling in Cache::Memcached

[George Schlossnagle]

dormando wrote:
> 
>> 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
>> perlish.
>>
>> George
> 
> 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.

Hi!  :)

George