Closed GoogleCodeExporter closed 8 years ago
I'm *pretty* sure this affects all versions. I remember very old versions
definitely being affected by this.
What changed are the clients.. some of them were updated to allow reading some
response data if sending starts to fail. There's not much the daemon can do in
this situation (especially for things like binprot where it has to immediately
write onto the wire). Are you accidentally testing different versions of
libmemcached as well?
Original comment by dorma...@rydia.net
on 30 Nov 2014 at 12:41
@dorma Actually version of libmemcached among these servers I tested differs
with each other. So the given test code (
https://gist.github.com/mckelvin/6aaf1d14e7866719a9bc ) is
libmemcached-neglected. It's in pure Python and believe it can be easily ported
to other languages.
At least this case is not effected:
➜ ~ uname -a Linux ubuntu-test 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ➜ ~ echo -ne "version\r\n" | nc localhost 11211 VERSION 1.4.13 ➜ ~ md5sum memcached_reproduce.py 7907ffe24977d7327c93dce170618828 memcached_reproduce.py ➜ ~ python memcached_reproduce.py switch: append VERSION 1.4.13
begin send end send begin recv end recv ➜ ~
Original comment by kelvin0...@gmail.com
on 30 Nov 2014 at 4:11
you're not switching versions, you're switching whole operating systems around.
On my system your script doesn't reproduce on the latest branch, .17, or .13.
If I add an extra zero to the number of commands being sent from the script,
all of those versions will hang.
This is the same as it's always been; if the event loop can't write more
responses, it can't parse more data inbound. It would have to start storing
more output internally somewhere.
Original comment by dorma...@rydia.net
on 1 Jan 2015 at 6:51
Original issue reported on code.google.com by
kelvin0...@gmail.com
on 20 Nov 2014 at 3:29