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

Report information
The Basics
Id:
44036
Status:
resolved
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
wsnyder [...] wsnyder.org
Cc:
AdminCc:

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



Subject: How to determine a timeout has occurred?
If a connection gets timed out, how can the calling perl code know this so it can report a warning? This may just be a documentation thing I missed, or otherwise a new status method is needed. (I see client.c:client_mark_failed is called, but no way to read the failure_count.) Thanks
Methods like set() return false when failure is reported by server (like NOT_STORED), and undef in the case of undetermined result. Most of the time undef means timeout (other cause is connection loss while sending request; events like garbage reply are unlikely).
On Wed Mar 11 10:21:24 2009, KROKI wrote:
Show quoted text
> Methods like set() return false when failure is reported by server (like > NOT_STORED), and undef in the case of undetermined result. Most of the > time undef means timeout (other cause is connection loss while sending > request; events like garbage reply are unlikely).
Thanks. I'm issuing a large get_multi. I made a testcase which simply does a put_multi of 1M numbers, then a get_multi with io_timeout to 0.1 (to test the timeout). I fairly regularly get a undef return, meaning timeout, which seems good. I think my real application sometimes get partial results on timeouts too, though the test case doesn't - perhaps this is because one server completes while another doesn't?
On Wed Mar 11 10:29:16 2009, WSNYDER wrote:
Show quoted text
> Thanks. I'm issuing a large get_multi. I made a testcase which simply > does a put_multi of 1M numbers, then a get_multi with io_timeout to 0.1 > (to test the timeout). I fairly regularly get a undef return, meaning > timeout, which seems good. I think my real application sometimes get > partial results on timeouts too, though the test case doesn't - perhaps > this is because one server completes while another doesn't?
Hard to tell. There's a bug RT#41390, which I don't have any clue about. I suspect timing issues, but have no reliable testcase to investigate. You may increase timeouts and/or inspect what really happens on the wire. Just to make it clear, to my understanding timeouts are a way to control the delay when some kind failure happens, and are not to improve latency of normal operations. Setting them too low will result in accumulation of more and more not-waited-for replies, which increase the latency further.
I consider this issue as resolved.


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.