Bug #44036 for Cache-Memcached-Fast: How to determine a timeout has occurred?

Wed Mar 11 09:56:12 2009 wsnyder [...] wsnyder.org - Ticket created

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

Wed Mar 11 10:21:24 2009 KROKI [...] cpan.org - Correspondence added

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

Wed Mar 11 10:21:24 2009 The RT System itself - Status changed from 'new' to 'open'

Wed Mar 11 10:29:16 2009 wsnyder [...] wsnyder.org - Correspondence added

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?

Wed Mar 11 11:03:58 2009 KROKI [...] cpan.org - Correspondence added

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.

Mon Nov 02 09:17:46 2009 KROKI [...] cpan.org - Correspondence added

I consider this issue as resolved.

Mon Nov 02 09:18:29 2009 KROKI [...] cpan.org - Status changed from 'open' to 'resolved'