This queue is for tickets about the Cache-Memcached-Fast CPAN distribution.

Report information
The Basics
Id:
81674
Status:
open
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
clh [...] pobox.com
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



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
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
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.
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.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.