Skip Menu |
 

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

Report information
The Basics
Id: 81674
Status: open
Priority: 0/
Queue: Cache-Memcached-Fast

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

Bug Information
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>
Download (untitled) / with headers
text/plain 137b
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
Download (untitled) / with headers
text/plain 548b
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
Download (untitled) / with headers
text/plain 462b
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.
Download (untitled) / with headers
text/plain 935b
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 is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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