Bug #81674 for Cache-Memcached-Fast: API for error codes?

Mon Dec 03 19:05:57 2012 clh [...] pobox.com - Ticket created

Subject:	API for error codes?
Date:	Mon, 03 Dec 2012 17:05:42 -0700
To:	bug-cache-memcached-fast [...] rt.cpan.org
From:	Chap Harrison <chap.harrison [...] me.com>

Have I overlooked the API for retrieving a detailed diagnostic message or code when an action such as set() returns false? Thanks Chap

Wed Dec 05 09:57:44 2012 finn_hakansson [...] yahoo.com - Correspondence added

From:

finn_hakansson [...] yahoo.com

The API doesn't offer such feedback. If get() returns undef, you can't know if it was a plain cache miss or an error. At least for set(), an undef means there was an error of some sort. It would be excellent if there was a way to know if the memcached client encountered an error with a memcached instance (and which memcached instance it was). On Mon Dec 03 19:05:57 2012, clh@pobox.com wrote: Show quoted text

> Have I overlooked the API for retrieving a detailed diagnostic message > or code when an action such as set() returns false? > > Thanks > Chap

Wed Dec 05 09:57:45 2012 The RT System itself - Status changed from 'new' to 'open'

Wed Dec 05 10:21:49 2012 KROKI [...] cpan.org - Correspondence added

On Mon Dec 03 19:05:57 2012, clh@pobox.com wrote: Show quoted text

> Have I overlooked the API for retrieving a detailed diagnostic message > or code when an action such as set() returns false?

As docs say set() returns false when server rejects the command, and IIRC the only reason for that is that the item is larger then ~1MB limit. You may set max_size parameter to a somewhat lower value to reject big items right on the client. For network errors set() returns undef.

Wed Dec 05 10:31:32 2012 KROKI [...] cpan.org - Correspondence added

On Wed Dec 05 09:57:44 2012, finn_hakansson@yahoo.com wrote: Show quoted text

> It would be excellent if there was a way to know if the > memcached client encountered an error with a memcached > instance (and which memcached instance it was).

While it's technically possible to add some call to retrieve exact reason of the last error, I have certain doubts that it'll worth it. C::M::F is an interface to a cache. When something wasn't retrieved from the cache for whatever reason one has to obtain the data by other means. Knowing the exact cause won't help much as there won't be anything one could do about that. IMHO any monitoring of memcached instances shouldn't be mixed with cache access from the application. For separate monitoring, periodically setting and getting a particular value from each memcached instance may be enough. https://github.com/tsee/p5-Cache-Memcached-Fast adds some server stats that may also be used for tuning.