Large multigets with binary protocol may hang client
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libmemcached |
Fix Released
|
Undecided
|
Trond Norbye |
Bug Description
(from http://
There's a problem with how memcached_purge attempts to flush the output buffer and read in responses which leads to hangs on read(2) calls. Fundamentally the issue is that memcached_purge expects to find a response for each request, when in general it has no way of knowing whether to a response will be forthcoming for quiet commands. This occurs at least in the situations where MEMCACHED_
Consider the multiget case: assume a multiget for 1,000 keys from a particular server; that only 100 getq commands fit in the 8K output buffer;
and that 10 of those 100 are cache misses. Only 90 responses are sent, and on memcached_purge's 91st call to memcached_
Related branches
- Trond Norbye (community): Needs Fixing
- Diff: None lines
- Brian Aker: Needs Fixing
-
Diff: 1146 lines7 files modifiedclients/memcapable.c (+714/-41)
libmemcached/memcached_delete.c (+1/-1)
libmemcached/memcached_get.c (+5/-2)
libmemcached/memcached_purge.c (+1/-1)
libmemcached/memcached_response.c (+7/-1)
libmemcached/memcached_stats.c (+2/-2)
tests/function.c (+154/-0)
This is caused by the fact that we count the GETKQ commands, but we cannot expect a return value from them. We should only count the NOOP command, and wait for that.